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tures  with  possibe  alternate  options;  in  addition,  a structure  will  support  many  func- 
tions also  with  alternatives.  Therefore,  structures  and  functions  arc  represented  and 
abstracted  independently  by  structural  object  hierarchies  and  by  functional  object 
hierarchies,  respectively,  and  the  relationship  between  these  hierarchies  are  modeled 
by  interaction  objects.  These  hierarchies  are  further  extended  to  directed  acyclic 

Invariants  ensure  that  the  structural  objects  and  the  functional  objects  are 
abstracted  correctly.  A set  of  rules  for  preserving  the  integrity  and  correctness  of 
composite  structural  objects  and  composite  functional  objects  are  presented.  The 
proposed  representation  also  supports  an  active  database  environment  by  modeling 
events  which  monitor  input  data  and  system  state,  and  initiate  and  terminate 
actions.  These  events  trigger  a set  of  constraints  to  ensure  the  consistency  of  the  sys- 
tem representation,  thus  making  this  paradigm  suitable  for  monitoring  and  simulatr 
ing  applications. 

The  utility  of  this  paradigm  is  demonstrated  in  two  areas-discrete  manufactur- 
ing and  computer  integrated  manufacturing.  In  discrete  manufacturing,  the 
structure-function  paradigm  helps  the  designer  in  making  design  choices  for  building 
robotic  workcells.  In  computer  integrated  manufacturing,  the  structure-function 
paradigm  is  used  to  integrate  engineering  databases  with  operational  information 
such  as  application  packages  into  one  integrated  environment. 


CHAPTER  I 
INTRODUCTION 

1.1  Problem  Overview 

The  information  age  has  generated  the  need  to  systematically  store  and 
manage  large  quantities  of  data.  These  data  are  diverse  in  content  and  require  spe- 
cialized techniques  for  modeling,  querying  and  storing  information.  The  diversity  is 
moat  apparent  in  the  engineering  domain,  where  a design  begins  its  life  at  the  draw- 
ing boards  and  evolves  to  a manufactured  product. 

A comprehensive  data  management  system  for  engineering  designs  should 
support  the  following  modeling  functions:  (a)  use  existing  designs  where  ever  pcesi- 
ble;  (b)  represent  and  manipulate  the  design's  structure:  (e)  represent  and  simulate 
the  design's  behavior;  (d)  represent  and  enforce  design  and  manufacturing  con- 
straints; and  (e)  support  design  evolution.  In  addition  to  modeling  a design,  an 
engineering  database  should  maintain  a part  catalog,  produce  a bill  of  materials 
(BOM)  for  a design,  and  interact  with  specialized  software  packages  such  os  simula- 
tion and  expert  design  tools.  It  is  clear  that  data  modeling  in  engineering  environ- 
ments should  be  a symbiosis  of  many  diverse  modeling  paradigms  and  should  be  a 
composition  of  many  systems. 

The  challenge  is  to  find  a comprehensive  framework  to  support  the  func- 
tionality of  an  engineering  application  described  above.  This  thesis  presents  a data 
representation  framework  called  the  structure- junction  (SF)  paradigm  to  model  the 
structural,  behavioral,  and  constraint  aspects  of  a design.  To  do  this,  engineering 
data  are  broken  down  into  (a)  data  about  the  physical  aspects  of  the  design,  such  as 


layout,  physical  interconnection,  physical  containment  and  proximity;  (b)  data  about 
the  functional  aspects  of  the  design,  such  as  representing  multiple  behavioral  charac- 
teristics of  the  same  design,  simulating  the  design  for  a given  input  disturbance,  and 
predicting  design  performance:  and  (c)  constraints  at  the  physical  and  functional  lev- 
els. Constraints  ensure  that  the  designed  products  conform  to  industry  standards  and 
product  specifications,  and  free  the  designer  from  the  chores  of  keeping  track  of  the 
effects  of  design  changes.  These  types  of  information,  i.e.,  passive  and  active,  are 
integrated  to  model  the  complex  semantics  of  an  engineering  design. 

The  separation  of  structural  information  from  functional  information  is 
important  in  comprehensively  specifying  complex  engineering  and  natural  systems 
[COR89|.  Without  this  separation  there  are  several  drawbacks;  the  most  notable 
ones  follow,  (a)  The  function  or  behavior  of  a domain  is  treated  os  second-class 
information  where  its  role  is  to  define  the  semantics  of  structural  data,  (b)  In  a 
purely  structural  model,  the  functional  model  of  an  application  is  forced  to  partition 
along  the  boundaries  of  structural  or  physical  objects,  thereby  either  losing  some 
behavioral  semantics  (of  the  system)  or  creating  artificial  structural  objects  to 
account  for  this  behavior.  The  functional  model  of  the  system  is  lost  as  the 
behavioral  information  is  buried  within  the  structural  model  of  the  application,  (c)  In 
a purely  functional  model,  when  combining  structure  and  function,  there  is  a ten- 
dency to  represent  the  structure  of  the  system  implicitly  by  coding  it  into  the  func- 
tional information;  thus  the  structural  model  of  the  system  is  not  explicitly 
represented,  (d)  In  general,  abstraction  among  functions  does  not  follow  abstraction 
among  structures,  and  vice  versa.  If  structures  are  not  separated  from  functions  dun 
ing  the  conceptual  specification  of  physical  systems,  the  structure  is  abstracted  and 
the  functions  are  tailored  to  fit  into  the  structural  framework,  or  vice  versa,  (e)  Mul- 
tiple functional  views  of  a structural  object  are  lost  as  the  function  is  encapsulated 
within  the  structure.  The  function  of  a given  structure  is  determined  by  its  context; 


when  functional  information  is  merged  with  structural  information,  this  context 
information  is  implied  through  the  encapsulation  principle.  Hence,  multiple  contexts 
cannot  be  used  in  determining  the  appropriate  behavior  of  the  system.  Similarly, 
multiple  structural  implementations  of  a function  suffer  from  the  same  problem 
[COROOa].  (f)  Current  database  systems  do  not  directly  support  simulation,  (g)  The 
designer  has  to  have  substantial  experience  with  data  modeling  to  adequately  convey 
design  semantics. 

This  dissertation  is  organized  as  follows.  The  next  section  is  a survey  of 
previous  results.  Chapter  2 shows  through  examples  that  one  real  world  object  can 
do  many  functions  and  that  one  function  may  be  jointly  carried  out  by  many  physi- 
cal objects.  Therefore,  an  object's  function  should  be  modeled  independent  of  the 
physical  object— this  gives  the  designer  greater  freedom  to  abstract  functions  to 
model  object  behavior.  An  engineering  design  is  then  modeled  by  designing  appropri- 
ate physical  objects  and  relating  them  to  the  functional  objects.  Chapter  3 gives  a 
detailed  description  of  the  SF  paradigm.  It  describes  the  modeling  requirements  for  a 
structural  object,  functional  object,  and  interaction  object.  The  interaction  between 
structures  and  functions  is  formalized  by  the  interaction  cycle,  and  this  formalism  is 
used  in  simulation.  Chapter  4 describes  a set  of  invariants  which  define  the  abstrac- 
tion semantics  for  a composite  structural  objects  and  composite  functional  objects. 
Chapter  5 shows  how  the  SF  paradigm  supports  constraints.  It  analyzes  constraint 
propagation  and  satisfaction  in  an  engineering  environment.  Chapter  6 discusses 
applications  of  the  SF  paradigm  to  (a)  design  robotic  workcells  by  guiding  the 
designer  to  select  among  multiple  design  choices;  (b)  store,  manage  and  retrieve  exist- 
ing design  information  using  integration  techniques  on  functional  descriptions;  and  (c) 
model  a computer  integrated  manufacturing  (CIM)  architecture  using  the  paradigm. 
Chapter  7 summarizes  the  results  of  this  dissertation  and  proposes  several  areas  for 


paradigm  is  flexible  and  modular  to  support  frequent 


In  summary,  the  SF 

design  updates:  it  is  formal  to  precisely  represent  structural,  behavioral,  and  con- 
straint data:  and  it  is  simple  and  direct  so  that  the  designer  can  concentrate  on  the 
design  and  not  on  the  details  of  semantic  data  modeling.  The  resulting  system  is 
powerful  enough  to  answer  queries  about  the  functional  (or  operational)  aspects  of 
the  system,  as  well  as  the  structural  (or  physical)  aspects  of  the  system,  e.g.,  "which 
parts  of  a flow  control  valve  may  leak  when  the  valve  is  operating  at  a pressure 
above  100  newtons  per  square  meter?" 

1.2  Survey  of  Related  Literature 

Database  modeling  is  the  process  of  capturing  our  perspective  of  the  real 
world  in  a representable  form.  This  representation  should  evolve  as  our  perspective 
of  the  world  changes.  An  engineering  data  model  should  reflect  the  characteristics  of 
the  application  domain  by  the  way  it  stores  and  manipulates  data.  Katz  [KAT85] 
presents  the  critical  data  modeling  issues  for  managing  large  engineering  design  appli- 
cations. The  rest  of  this  chapter  is  a survey  of  the  important  modeling  paradigms, 
concentrating  on  those  used  for  engineering  applications.  Important  research  results 
in  engineering  data  modeling  will  be  pointed  out  in  the  survey. 

The  relational  data  model  [COD70]  and  its  extensions  are  popular  in 
engineering  applications.  The  relational  model  consists  of  relations  or  tables  that 
store  a set  of  uniformly  formated  records.  Each  record  Is  an  ordered  set  of  atomic 
data  values  called  attributes;  these  values  are  drawn  from  relevant  domains.  Every 
record  is  uniquely  identified  by  a primary  key.  The  real  world  is  represented  by  a set 
of  tables  and  by  a set  of  functional  dependencies,  multivalued  dependencies,  and 
other  semantic  constraints  (ST07S,  ULL80].  The  relational  model's  simplicity  and 
naturalness  make  it  widely  acceptable  for  business-oriented  applications.  The  two 


popular  relational  query  languages,  SQL  and  QUEL  [ELM8fl|,  are  used  for  dcHning 
schemas  (sets  of  relations),  populating  schemas,  and  manipulating  data  in  these  sche- 
mas. The  RM/T  [COD79]  is  an  extension  of  the  basic  relational  model  where  gen- 
eralizations, aggregations  [SMI77],  null  values,  etc.,  are  used  to  capture  real  world 

The  strengths  of  the  relational  model  become  its  weakness  when  it  is  used 
for  modeling  engineering  data.  The  regular  record  structure  with  atomic  data  values 
cannot  model  repeating  groups  and  hierarchical  information  directly  [LOR83, 
HAS82aj.  The  disjoint  tabular  relational  structure  cannot  cluster  related  properties 
of  an  object  in  one  place,  making  the  model  difficult  to  use  because  it  requires  a 
detailed  knowledge  of  the  underlying  schema  definition  [KEM87b],  The  performance 
is  poor  due  to  the  large  number  of  relations  accessed  to  retrieve  a complex  object 
[VBAS8,  GUT82).  Moreover,  there  is  no  way  to  model  the  dynamic  properties  of  a 
domain. 

Today,  the  basic  relational  model  is  changed  to  alleviate  these  shortcom- 
ings. One  prominent  research  effort  at  the  University  of  California,  Berkeley, 
upgraded  their  INGRES  relational  system  [ST076]  and  QUEL  query  language  to  the 
POSTGRES  system  and  the  POSTQUEL  query  language,  respectively  [STO86, 
ROW87|.  The  extensions  to  the  relational  model  include  complex  objects  [ST084], 
abstract  data  types  (ST083,  0NG8I],  definition  of  procedures  [ST087b|,  and  the  use 
of  rules  [ST087a],  Complex  objects  are  defined  by  a set  of  commands  or  queries  on 
more  basic  data  objects*  Queries  are  treated  as  a data  typo,  thus  permitting  general- 
ization. aggregation,  and  the  sharing  of  a sub-object  [ST087b],  Abstract  data  types 
(ADTs)  are  defined  on  each  column  of  a relation  (instead  of  the  whole  relation)  and 
include  (a)  its  own  set  of  operations  and  (b)  information  for  the  efficient  access  of 
storage  structures.  The  query  language  is  extended  to  support  transitive  closure,  his- 
torical data,  rules,  and  inheritance  in  a type  hierarchy  (GUT82,  STO88]. 


In  another  effort,  IBM  extended  their  System  R relational  model  [AST76] 
by  defining  long  fields,  and  complex  objects,  and  by  including  procedures  in  their 
database.  Image  data,  programs,  input  and  output  sequences  to  programs,  and  text 
documents  are  stored  in  long  fields.  Long  fields  may  span  several  pages  and  are 
irregular.  A complex  object  is  a collection  of  semantically  related  tuples  from 
different  relations  into  a angle  database  entity  [HAS82a,  HAS82b,  LOR83|.  Tuples 
are  arranged  in  a hierarchy  by  including  the  key  of  the  parent  tuple  as  a foreign  key 
in  the  child  tuple.  Special  attributes  describe  linkages  among  tuples  other  than  those 
defined  by  the  hierarchical  structure.  The  SQL  query  language  was  expanded  to  han- 
dle complex  objects  and  long  fields.  The  cursor  which  kept  the  tuple-by-tuple  posi- 
tion of  the  result  could  now  index  to  a specific  position  within  a long  field. 

In  a parallel  effort  by  IBM  in  Heidelberg,  W.  Germany,  the  relational  model 
was  extended  to  the  non-first-normal-form  (NF*)  data  model  to  support  object 
hierarchies  [DAD86].  These  hierarchies  represent  complex  objects.  The  main 
features  of  this  model  are  (a)  uniform  treatment  of  flat  tables  and  nested  tables;  (b) 
relations  occurring  as  attribute  values  of  tuples;  {c)  support  of  composite  data  types 
such  as  list  (an  ordered  set  of  elements),  relation  (an  unordered  table)  and  tuple  (an 
instance  of  a relation);  and  (d)  an  extension  to  SQL  where  lists  or  relations  are 
accessed  as  attributes  of  a relation  and  the  user  can  describe  the  nesting  level  of  the 

The  functional  data  model  (FDM)  (SIB77]  proposed  a powerful  paradigm  to 
model  information.  The  major  contribution  of  this  research  was  to  recognize  the 
functional  view  of  data  modeling  and  to  develop  functional  languages  for  data 
specification  |ATK82,  BUN82a,  BUN82b|.  The  FDM  uses  a directed  graph  of  enti- 
tles and  functions  to  model  the  real  world;  the  entities  are  nodes  and  the  functions 
are  arcs.  Entities  are  real  world  objects  and  functions  are  cither  properties  of  these 
objects  or  relationships  among  objects.  Shipman  (SHIP81)  formalized  the  functional 


by  introducing  the  DAPLEX 


language.  The  FDM 


represent  derived  data,  which  means  defining  new  properties  based  on  existing  pro- 
perties, supertype-subtype  hierarchies,  and  inverse  functions.  The  concept  of  general- 
ization of  entities  and  functions  in  the  FDM  is  formalized  by  Dayal  and  Hwang 
[DAY84|.  Atkinson  and  Kulkarni  |ATK82]  extended  the  FDM  by  permitting  (a)  the 
addition  and  deletion  of  functions  at  any  time,  thus  supporting  schema  evolution,  and 
(b)  the  manipulation  of  user-defined  views. 

The  research  effort  of  CCA  (Computer  Corporation  of  America)  extended 
the  functional  model  and  the  DAPLEX  language  for  advanced  database  applications 
such  as  geometric  data,  geographic  data,  and  temporal  data  (ORE88|.  The  new 
model  is  called  the  PROBE  data  model  (PDM)  (MAN86).  The  PDM  is  object- 
oriented,  i.e.,  object  classes  can  be  added  to  increase  the  functionality  of  a schema. 
An  object  class  is  defined  ns  an  abstraction  of  data  types  and  associated  operations 
[DAY87b|.  Object  classes  are  organized  in  an  abstraction  hierarchy.  In  the  FDM, 
the  input-output  correspondences  are  stored  explicitly  by  the  functions,  whereas  in 
the  PDM  a function  can  also  compute  its  output  values  with  procedures.  This  makes 
it  possible  to  have  a uniform  modeling  construct  to  store  data  and  operations  on 
data.  In  PDM,  complex  objects  are  modeled  as  entities  and  functions.  These  func- 
tions are  either  entity  valued  or  set  valued  [DAY87a]  and  represent  relationships  (a) 
among  complex  objects  and  their  components  and  (b)  among  components. 

Semantic  data  models  with  a rich  set  of  association  types  are  used  to  model 
engineering  data.  The  semantic  association  model  (SAM*)  (SU86],  and  the  event 
model  (EM)  [IGN82]  are  two  prominent  examples  in  this  class  used  for  modeling 
engineering  data.  The  SAM*  has  seven  association  types-membership,  aggregation, 
generalization,  interaction,  composition,  cross-product,  and  summarization.  The 
cross-product  and  summarization  association  types  are  used  for  modeling  statistical 
data.  Complex  data  types  such  as  text,  vector,  matrix,  and  time  series  are  basic  data 


types  and  arc  useful  for  engineering  applications.  Hierarchical  structures  are 
represented  by  nested  tabular  relations  called  G-relations. 

The  SAM*  was  extended  to  an  object-oriented  model  called  OSAM* 
[SU89].  Here  entities  and  associations  are  treated  uniformly  as  objects.  Links 
represent  the  connection  between  objects.  Operations  and  rules  are  included  in  the 
class  definition  to  account  for  the  behavioral  part  of  the  application.  Currently  a 
navigational  object  query  language  (OQL)  is  being  developed  based  on  objects  and 

The  EM  consists  of  objects  and  application  events.  Objects  are  further 
classified  as  descriptor  objects  (or  atomic  objects)  and  abstract  objects  (or  nonatomic 
objects).  Abstract  objects  are  defined  in  terms  of  their  relationships  with  other 
objects  through  attributes.  Application  events  specify  a transaction  type  by  (a)  a set 
of  parameters  defined  on  some  abstract  object,  (b)  a set  of  subtypes  which  the  appli- 
cation event  manipulates,  and  (c)  a set  of  actions.  Actions  are  structured  by  using 
control  structures  such  as  sequencing,  conditional  selection,  and  iteration. 

The  EM  was  extended  to  better  describe  engineering  design  data  with  three 
primitives  |MCL83|.  A design  is  represented  as  a directed  acyclic  graph  consisting  of 
LEAF  nodes,  which  represent  the  atomic  entities  of  a design  hierarchy;  AND  nodes, 
which  describe  the  part-of  and  composed-of  relationships;  and  the  OR  nodes,  which 
describe  alternative  implementations  of  a design  by  the  is-implemcnted-by  relation- 
ship. This  model  captures  the  notions  of  complex  objects  and  versions  in  a simple 
manner  by  using  the  AND  and  OR  nodes,  respectively,  to  abstract  the  primitive  enti- 
ties of  a system. 

The  most  popular  drive  toward  modeling  engineering  data  is  the  object- 
oriented  approach.  The  object-oriented  paradigm  originated  from  the  programming 
language  domain  [GOL83)  and  was  adopted  for  database  systems  (COPS-t.  MAI 85, 
ZD085).  All  real  world  entities  are  treated  as  objects.  Each  object  has  a set  of 


properties  called  instance  variables  and  an  associated  set  of  operations  called 
methods.  Methods  fully  define  the  behavior  of  the  object.  Instance  variables  and 
methods  arc  not  visible  outside  the  object.  Objects  interact  with  each  other  by  send- 
ing messages;  these  messages  invoke  a method  in  the  receiving  object.  Similar 
objects  are  grouped  into  classes,  and  classes  are  arranged  into  superclass/subciass 
hierarchies,  or  DAGs.  Class  variables  describe  the  properties  of  the  class  and  are 
shared  by  all  objects  in  the  class.  Properties  and  methods  of  a superclass  are  inher- 
ited by  all  its  subclasses. 

As  noted  earlier,  the  FDM  and  the  SAM*  have  already  adopted  the  object- 
oriented  approach.  The  POSTGRES  system  (an  extended  relational  system 
described  earlier)  has  the  power  of  an  object-oriented  system  for  modeling  engineer 
ing  data.  The  NF"  model  [DAD 86]  is  extended  to  an  object-oriented  model  called 
the  11 2 D7  model  (relational  robotics  database  system  with  extensible  datatypes) 
[KEM87bj.  In  the  R2D2  model,  object  behavior  is  stored  in  user-defined  abstract 
data  types,  (ADTs).  These  ADTs  are  defined  from  more  primitive  user-defined  data 
types.  The  same  data  manipulation  language,  an  extension  of  SQL,  is  used  both  for 
defining  operations  inside  an  ADT  and  for  queries  on  the  nested  relations.  Each 
ADT  is  mapped  to  an  NF2  relation. 

The  object-oriented  research  group  at  MCC  (Microelectronics  Computer 
Corporation,  Austin,  Texas,)  has  developed  an  object-oriented  model,  called  ORION, 
for  modeling  advanced  applications-CAD/CAM,  AI  (artificial  intelligence),  OIS 
(office  information  systems)  [BAN87a],  and  multimedia  databases  (WOE86|.  This 
model  has  all  the  features  of  an  object-oriented  system  noted  earlier.  The  major  lim- 
itation of  the  object-oriented  approach  when  used  for  modeling  engineering  data  is 
the  absence  of  object  clustering.  ORION  addresses  this  limitation  by  adding  compo- 
site objects  and  composite  object  hierarchies  [KIM87b]  and  by  defining  operations  on 
complex  objects  [KIM87a,  BAN88).  A composite  object  is  defined  as  a collection  of 
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instance  variables,  where  each  instance  variable  has  a composite  link  pointing  to  one 
subobject.  (Note  that  instance  variables  also  represent  the  descriptive  properties  of 
an  object).  These  subobjects  are  mutually  exclusive  and  the  composite  link  relates 
only  one  subobject  instance  to  a composite  object.  The  second  contribution  is 
schema  evolution  in  object-oriented  databases  (BAN87b).  A set  of  twelve  rules 
preserves  the  schema  structure  during  evolution.  The  consistency  of  the  database 
schema  is  defined  by  a set  of  five  invariants. 

In  a recent  dissertation,  Cammarata  [CAM86]  developed  an  object-oriented 
dnta  model,  called  ODM,  for  CAD/CAM  applications.  The  basic  features  of  ODM 
are  intension,  which  is  a generic  object  description;  instance,  which  is  an  instantiation 
of  an  intension  and  represents  an  object  in  the  real  world;  description,  which  associ- 
ates an  instance  with  an  intension;  and  extension,  which  is  a collection  or  a set  of 
instances.  These  four  constructs  are  used  to  (a)  represent  complex  generalization  and 
aggregation  structures;  (b)  model  semantic  objects  and  relationships;  (c)  include 
inferencing  capabilities:  and  (d)  provide  semantics  to  model  the  intensions!  aspects 
and  the  modeling  primitives  of  a CAD  domain.  This  work  recognizes  the  importance 
of  supporting  dynamic  schemas  and  composite  objects,  modeling  heterogeneous  data 
types,  using  metadata  to  integrate  distributed  CAD  applications,  and  maintaining 

In  another  recent  dissertation,  Ketabchi  [KET80]  describes  an  object- 
oriented  framework,  called  ODM,  to  mode]  CAD  data.  Component  aggregation  is 
the  primary  data  abstraction  mechanism  where  objects  with  the  same  types  of  parts 
are  considered  equivalent.  Composite  objects  represent  grouts  of  objects  that  are 
related  by  the  part-subpart  relationship.  The  ODM  represents  objects  by  templates 
that  are  the  intensional  descriptions  of  objects;  these  templates  consist  of  properties 
and  operations.  Properties  and  the  relationships  among  objects  are  modeled  by  func- 
tions, as  in  the  FDM  described  earlier.  Operations  are  modeled  by  Smalltalk-like 
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x for  the  object.  Active  data  (procedures)  and  passive 
data  (functions)  are  aggregated  into  one  template.  The  other  important  CAD  issue 
discussed  is  design  version  management.  A design  evolves  by  refining  a template;  the 
new  template  has  at  least  all  the  information  in  the  original  template. 

extent  to  which  they  support  CAD  applications.  Servio  Logic  Corporation  has 
developed  an  object-oriented  database  system  and  language  called  GemSlone  and 
OPAL,  respectively  (COP84).  GemStone  is  a general-purpose  database  system  that 
uses  a class  mechanism  to  define  a hierarchy  of  types.  Similar  types  may  share 
instance  variables  (attributes)  and  operations  through  inheritance.  Messages  and 

supports  (or  proposes  to  support)  dynamic  schema  modification,  supports  arbitrary 
data  items  as  values,  captures  past  states  of  a database,  and  supports  queries  on  these 
states.  The  object-oriented  language,  OPAL,  has  many  features  in  common  with 
Smalltalk-80  [GOL83|. 

Ontologic,  Inc.,  has  developed  an  object-oriented  database  system  called 
VBASE  (AND87).  The  goal  of  VBASE  is  to  combine  a procedural  object  language 
and  persistent  objects  into  one  integrated  system.  Like  GemStone,  it  has  a taxonomy 
of  types  (neither  system  supports  a DAG,  i.e.,  a directed  acyclic  graph,  of  types  with 
multiple  inheritance,  as  of  now),  where  subtypes  inherit  properties  (attributes)  and 
procedures,  and  can  either  add  to  or  refine  the  existing  properties  and  procedures  of 
the  supertypes.  The  system  supports  1:1,  l:n,  and  n:m  relationships  among  objects, 
triggering  of  methods,  inverse  relationships,  and  the  handling  of  exceptions.  The  sys- 

The  VBASE  system  is  based  on  the  abstract  data  type  paradigm  and  the  CLU  pro- 


Smalltalk.  There  is  a strong  emphasis  on  separating  the  specifications  and  implemen- 
tation of  the  system.  The  languages  for  VBASE  include  a type  definition  language 
(TDL)  for  data  definition,  and  the  C object  programming  language  (COP)  for  data 
manipulation.  The  TDL  is  strongly  typed,  block  structured,  and  can  type  members 
of  aggregate  objects,  whereas  COP  is  a superset  of  C programming  language 
[KER78],  In  a recent  upgrade  of  VBASE  called  ONTOS  (currently  a beta  version) 
the  TDL  and  the  COP  are  replaced  by  the  C++  programming  language  (STR87). 

The  above  survey  concentrates  on  the  evolution  of  data  base  techniques  to 
solve  engineering  data  modeling  problems.  Now,  other  research  results  specially  use- 
ful for  modeling  engineering  data  are  presented.  The  meet  important  contributions 
to  modeling  engineering  data  are  the  definition  of  composite  objects,  the  definition  of 
hierarchies  of  clustered  objects,  and  the  definition  of  query  languages  to  handle  com- 
plex objects.  Composite  objects  are  supported  by  all  the  above  models  in  one  way  or 
another.  Buchmann  and  Peres  de  Celis  [BUC85],  Buchmann  et  al.  (BUC86),  Johnson 
et  al.  [JOH83],  Chu  et  al.  [CHU83],  and  many  others  recognize  that  composite 
objects  are  fundamental  to  CAD  applications.  Batory  and  Buchmann  [BATS-I] 
defined  molecular  aggregation  to  represent  composite  objects  at  different  levels  of 
abstraction.  A composite  object  consists  of  two  parts:  an  interface  and  an  implemen- 
tation. Batory  and  Kim  [BAT85]  present  a set  of  modeling  features  to  integrate 
composite  objects  and  design  versions  for  VLSI  CAD  into  one  framework.  Query- 
processing  strategies  on  complex  objects  are  described  in  (a)  Rosenthal  et  al. 
[ROS84],  who  use  a knowledge-based  approach  on  part  hierarchies:  (b)  Dadam  et  al. 
[DADSG]  who  extend  the  SEQUEL/SQL  language  for  nested  relations,  and  (c)  Kim 
ct  al.  [KIM87a]  who  use  an  object-oriented  language  to  retrieve  or  manipulate  entire 
composite  objects. 

A design  will  have  many  alternates  or  versions  before  the  final  design  is 
sent  in  for  manufacturing.  McLeod  et  al.  [MCL83]  define  a version  as  a consistent 
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state  of  the  design  that  can  no  longer  be  updated.  Version  mangement  techniques 
range  from  simple  revisions  [VVON79]  to  a powerful  version  model  that  supports 
automatic  changes  with  semantic  rules  [l<AT87|.  Eastman  [EAS80]  proposes  to  save 
updates  temporarily  in  checkpoint  files,  these  files  are  alternates  to  the  original 
design.  As  alternates  can  branch  from  other  alternates,  this  generates  a tree  of 
checkpoint  files.  At  some  stage  of  the  design,  all  these  files  are  merged  into  the  per- 
manent database  that  holds  the  original  design.  Katz  and  Chang  [KAT87]  represent 
a design  by  (a)  configuration  relations  (similar  to  the  AND  relationship  of  McLeod  et 
al.  [MCL83]);  (b)  version  relations,  which  tie  together  different  versions  of  the  same 
logical  object;  and  (c)  equivalence  relations,  which  identify  different  representations 
of  the  same  real  world  object. 

In  a concurrent  dissertation,  Ahmed  [AHMS9]  proposes  versioning  for  CAD 
databases  based  on  an  object-function  model.  Properties  of  an  object  are  divided 
into  versionable  and  nonversionable  sets.  During  the  design  process,  an  object  can  be 
in  three  versionable  states-transient,  stable,  and  verified.  Storage  strategics  and 
change  notification  protocols  for  cooperative  design  environments  are  also  developed. 

The  digital  circuit  automation  system  of  Blackburn  and  Thomas  [BLA85] 
employs  two  hierarchies-one  to  represent  behavioral  information,  and  the  other  to 
represent  the  structural  information.  The  user  specifies  the  behavior  of  the  design  in 
the  instruction  set  processor  language  (ISPS),  which  is  then  automatically  translated 
to  a functional  hierarchy.  The  functional  hierarchy  is  used  to  generate  a correspond- 
ing structural  design.  Davis  [DAV84]  uses  structural  and  functional  information  to 
diagnose  electrical  circuits  by  reasoning  from  first  principles.  Walker  and  Thomas 
[WAL85|  use  three  orthogonal  axes  to  represent  digital  circuit  designs-behavioral. 
structural,  and  physical.  Along  each  of  these  axes,  multiple  levels  of  design  abstrac- 
tion are  represented.  Decomposition  in  each  axis  is  not  symmetric;  therefore,  one 
behavioral  domain  element  may  correspond  to  many  structural  domain  elements. 


Also,  many  structural  domain  elements  may  correspond  to  a single  physical  domain 
element.  This  model  is  used  to  synthesize  logic  circuits  from  high-level  behavioral 
descriptions. 

The  general  architecture,  engineering,  and  construction  (ACE)  reference 
model  (GARM)  (IS089]  is  a product  specification  model  developed  by  the  ACE  com- 
mittee on  international  standards  organization/standard  for  the  exchange  of 
product-model  data  (ISO/STEP).  The  STEP  effort  aims  to  produce  the  first  interna- 
tional standard  for  data  exchange;  and  GRAM  is  developed  within  the  STEP  efiort 
to  integrate  ACE  applications  and  develop  and  integrate  generic  software  products. 
In  GRAM,  a product  is  specified  in  terms  of  an  hierarchy  of  functional  units  and 
technical  solutions.  The  functional  units  describe  the  requirements  and  the  technical 
solutions  represent  the  structures  that  satisfy  the  functional  units. 

Outside  the  database  literature,  Bobrow  and  VVinograd  [BOB77]  store  pro- 
cedures along  with  other  data  within  one  frame  structure.  Here,  an  unnatural  1:1  or 
l:n  structure-function  relationship  is  forced  on  the  designer.  From  the  programming 
language  peispective,  Atkinson  [ATK85]  points  out  the  need  for  making  procedures 
as  persistent  data  objects. 

Sussman  and  Steel  |SUS80|,  Kuipers  [KUI84],  and  Davis  [DAV84]  exploit 
the  power  of  modeling  a physical  system  in  terms  of  structures  and  behavior  to 
enforce  constraints,  to  reason  about  causality,  and  to  diagnose  system  faults.  Forbus 
[FOR8-I]  explains  that  "no-function-in-structure"  is  a fundamental  requirement  for 
qualitative  reasoning  of  physical  systems. 

In  engineering  design  and  simulation,  modeling  object  behavior  is  as  impor- 
tant as  modeling  the  object  structure  (AFS8S,  BLA85,  VVAL8S,  KEM87aj.  The  sys- 
tems surveyed  above  use  ADTs  |ST083,  ONG84,  KEM87b|,  procedures  [ST087b], 
rules  [ST087a,  SU89],  operations  [DAY87b,  SU89),  and  functions  [MAN86J  to  model 
object  behavior.  Each  of  these  mechanisms  captures  the  dynamic  properties  of  the 
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real  world  by  focusing  on  the  manipulation  of  static  data  values.  Modeling  object 
behavior  is  difficult,  and  there  is  no  agreement  as  to  the  best  way,  as  seen  by  the 
above  survey.  In  most  of  the  above  systems,  the  structural  and  functional  data  are 

template,  or  are  completely  disjoint  where  the  behavioral  data  sits  on  the  structural 
data  as  an  application  package. 

Bond  graphs  [TH075J  uniformly  represent  engineering  domains  in  terms  of 
components  that  exchange  energy  and  power  through  connection  ports.  Each  port  is 
a bond  defined  by  two  variables-effort  and  flow.  The  product  of  these  variables 
denotes  the  energy  transferred  between  system  components,  whereas  the  quotient  of 
these  variables  denotes  the  resistance.  Components  are  defined  by  standard  word 
notations,  and  the  bond  junctions  are  defined  in  terms  of  parallel  or  series  connec- 
tions (as  in  electric  circuits).  Bond  graphs  also  show  causality  and  the  direction  of 
flow  of  positive  potential.  These  features  make  bond  graphs  suitable  for  modeling 
and  simulating  physical  systems. 


MOTIVATION  FOR  THE  STRUCTURE-FUNCTION  MODELING  PARADIGM 


2.1  Introduction 


Engineering  design,  like  any  other  design  activity,  is  an  exploratory  and 
iterative  process  where  the  preliminary  design  undergoes  many  changes  before  it 
meets  the  product  specifications  and  acceptance  tests.  To  reduce  the  total  time 
spent  from  design  to  manufacture,  the  design  process  should  take  into  account 
manufacturing  constraints.  Simulation  plays  an  important  role  by  validating  the 
functional  characteristics  of  a design.  Data  generated  during  simulation  dictate 

related,  and  this  relationship  should  form  the  baas  for  specifying  an  engineering  data- 
base system  to  store  and  manipulate  design  data. 


An  engineering  database  specification  system  should  (a)  provide  the  neces- 
sary tools  to  formulate  and  store  the  design  semantics,  i.e.,  all  meaningful  relation- 
ships in  a design;  (b)  use  manufacturing  constraints  in  design,  i.e.,  design  for 
manufacture;  (c)  provide  relevant  abstraction  techniques  to  represent  complex  sys- 
tems; (d)  support  evolution  of  design  prototypes;  (c)  support  simulation  of  portions  of 
a partially  completed  design;  and  (f)  provide  high-level  requirement  specification 
language  to  express  semantics  and  constraints  for  design,  simulation  and  manufactur- 
ing. These  requirements  are  common  to  electrical  circuit  design,  machine  design, 
hydraulic  and  pneumatic  system  design,  chemical  plant  design,  structural  (ships, 
aerospace,  etc.)  design,  and  most  engineering  domains. 
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Today  such  engineering  database  systems  are  not  available.  All  structural 
data  are  stored  in  databases,  and  all  functional  (or  behavioral)  data  of  the  domain 
are  embedded  in  special-purpose  application  programs.  These  software  application 
packages  which  address  different  phases  of  the  design  and  implementation  cycle  are 
independent  of  one  another,  have  different  data  organizations,  and  have  different 
input-output  physical  formats.  This  nonuniform  treatment  of  structural  and  func- 
tional data  in  current  database  systems  has  made  it  difficult  to  build  a viable  plat- 
form for  automating  the  engineering  design  and  manufacturing  processes. 

2.2  Engineering  Design  and  Simulation 

In  engineering  design,  as  is  the  case  in  any  other  design,  the  primary  func- 
tion of  the  product  is  first  specified.  The  primary  function  is  decomposed  into  a set 
of  more  basic  functions.  This  decomposition  is  done  until  the  complete  behavior  of 
the  system  is  specified.  During  the  decomposition  process,  the  primary  function  is 
supported  by  secondary  functions  which  are  not  important  by  themselves  but  are 
needed  for  a working  design.  For  example,  the  primary  function  of  a flow  control 
valve  is  to  vary  the  flow  of  a liquid,  while  the  secondary  functions  are  to  support  the 
spindle,  and  to  prevent  leakage.  After  specifying  the  functional  aspects  of  the  design, 
the  structural  realization  of  these  functions  are  synthesized  to  produce  an  initial 
design.  For  example,  the  flow  control  valve  needs  a spindle,  a housing,  and  various 
bushes  for  support  and  for  sealing  the  liquid.  The  initial  design  specification  is  then 
refined  by  defining  new  functions  or  adding  new  supporting  functions.  The  process  is 
repeated  until  the  simulation  results  indicate  that  the  product  specifications  are  real- 
ized. The  design  is  usually  carried  out  by  a team  of  designers  with  their  own  per- 
spectives of  the  design.  These  perspectives  are  coordinated  into  one  design,  and  this 
design  is  analyzed  for  design  flaws.  If  the  design  meets  all  the  design  function 


specifications,  it  is  checked  for  manufacturability.  When  the  design  is  deemed 
manufacturable,  it  is  released  to  the  shop  floor.  Figure  2.1  shows  the  phases  of  a 
design  process. 

In  all  engineering  designs,  structural  objects  (i.e.,  structural  data  which 
represent  the  physical  or  logical  components  of  the  design)  are  assembled  together  in 
unique  ways,  and  this  interconnection  is  based  on  the  interfaces  of  the  participating 
objects.  Hence,  each  structural  object  has  an  interface  part  and  an  internal  part. 
Objects  are  grouped  together  into  components  or  subassemblies  which  in  turn  are 
grouped  into  larger  components,  and  so  on  until  the  whole  design  is  represented. 
These  groupings  are  again  based  on  object  interfaces  and  their  interactions.  The 
actual  object  groups,  however,  are  determined  by  (a)  physical  boundaries  that  can  be 
manufactured  or  assembled,  like  maximum  length/weight  of  a beam  or  the  pins  of  an 
IC  logic  chip;  and/or  (b)  the  group’s  function,  e.g.,  the  arithmetic  logic  unit  (ALU)  or 
the  central  processing  unit  (CPU)  are  distinct  functional  objects  in  microprocessor 

Simulation  is  essential  in  complex  system  design.  Simulation  is  the  study  of 
system  behavior  by  observing  state  changes  [ZEI85].  In  complex  environments,  sys- 
tem behavior  is  analysed  by  decomposing  the  overall  working  into  subfunctions  and 
observing  the  state  sequences  of  each  component  independently.  Here,  the  subfunc- 
tions interact  by  inputs  and  outputs  alone,  be.,  outputs  of  one  component  feed  the 
input  of  another  component  [GOV87|.  The  advantages  of  this  representation  in  simu- 
lation are  simplicity,  ease  of  control,  and  modularity.  Faults  are  isolated  by  identify- 
ing the  malfunctioning  structural  components,  and  the  design  can  be  simulated  at 
different  levels  of  abstraction. 

From  the  above  discussion,  the  functional  description  of  the  system  is 
needed  in  the  design  specification  phase  and  in  the  simulation  phase.  Therefore,  the 
functional  specification  is  as  important  as  the  structural  specification  for  engineering 


Figure  2.1  Design  and 


1 analysis  cycle. 
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database  systems.  Functional  objects  (i.e„  functional  data  which  represent  one 
behavioral  aspect  in  the  design)  have  an  external  part  and  an  internal  part.  Func- 
tional objects  are  grouped  together  into  subfunctions  which  in  turn  are  grouped  into 
larger  functions.  These  groupings  are  based  on  function  interfaces  and  their  interac- 
tions. The  modularity  of  functional  objects  and  the  predictability  of  its  response  to 
an  input  stimulus  suggests  that  functional  objects  should  be  treated  as  data. 

In  some  application  domains,  physical  boundaries  separate  a physical  object 
into  components  with  which  functional  objects  coincide,  making  the  structural  and 
functional  representations  for  a design  easy  to  model.  A prominent  example  is  digital 
design  where  the  logic  chip,  as  a component,  has  clear  physical  boundaries  and  a 
designated  function.  In  most  domains,  however,  the  same  structure  performs  more 
than  one  function,  thus  feeing  the  structural-functional  modularity.  This  means  that 
the  structural  decomposition  and  functional  decomposition  of  the  same  design  are  not 
symmetric.  As  the  design  evolves,  so  should  its  stored  representation  in  the  database. 
These  changes  will  occur  in  the  structural  and  the  functional  domains  at  different 
times  and  at  different  frequencies.  For  example,  the  functional  data  evolve  more  fre- 
quently during  the  early  part  of  the  design  process,  whereas  the  structural  data 
evolve  more  frequently  during  the  intermediate  and  the  final  stages  of  the  design  pro* 
cess.  Therefore,  the  evolution  patterns  in  the  structural  and  functional  domains  sug- 
gest that  the  design  data  should  model  the  function  and  structure  separately  (a)  to 
ensure  modularity  in  structure  and  modularity  in  function  and  (b)  to  have  a clean 
interface  between  structural  and  functional  descriptions. 

2.3  Motivating  the  Structure-Function  Paradigm  by  Examples 

All  natural  and  man-made  systems  that  are  inherently  complex  (e.g.,  bio- 
logical systems,  engineering  systems)  do  not  necessarily  have  behaviors  that  are 


encapsulated  within  the  boundaries  of  a structural  object;  on  the  other  hand,  they 
have  complex,  interdependent  functional  components  that  relate  to  the  system  struc- 
tures. An  obvious  example  is  the  human  body;  the  circulatory  and  the  respiratory 
systems  are  complex  functional  systems  that  have  their  own  models  and  abstractions 
to  represent  their  functions.  These  functions  relate  to  different  organs  (structures); 
for  example,  the  lungs  belong  to  both  the  functional  systems,  whereas  the  heart 
belongs  to  the  circulatory  system.  The  heart  and  lungs  are  represented  as  complex 
structural  objects.  Both  these  structures  are  contained  inside  the  ribcage,  another 
structural  entity  and  a part  of  the  skeletal  body  framework.  Here,  it  is  easy  to  see 
that  structural  abstraction  (aggregation  of  parts)  does  not  follow  abstraction  of  func- 
tions, i.e.,  the  abstraction  hierarchies  in  the  structural  and  the  functional  domains  are 
not  isomorphic. 

Two  examples  from  the  engineering  domain  will  illustrate  the  role  of  struc- 
ture and  function  discussed  above.  The  first  example  from  the  mechanical  engineer- 
ing domain  shows  the  nature  of  structure-function  relationship  in  engineering  design 
(PAH83).  The  second  example  from  the  digital  design  domain  will  help  to  crystalise 
modeling  requirements  for  structural  objects,  functional  objects,  and  their  associa- 
tions in  an  engineering  design. 

Consider  a simplified  How  control  valve  that  regulates  the  flow  of  liquid 
shown  in  Figure  2.2.  The  function  of  this  valve  is  to  transmit  liquid  from  one  point 
to  another  when  the  spindle  opens  and  to  stop  the  liquid  when  the  spindle  obstructs 
the  flow.  This  overall  function  can  be  broken  down  into  three  subfunctions  listed 
below: 

FI:  pass  liquid 

F2:  vary  passage  dimension 

F3:  liquid  flow  control 


Spindle 


Threaded 

bearing 

bush 


2.2  Flo 


am  Pahl  and  Beitz  |PAH83], 


These  subfunctions  arc  broken  down  further  into 


FI  - channel  liquid,  Fll 

- seal  liquid,  F12 

F2  - control  channel  opening,  F21 

- hold  the  mechanism  for  flow  control,  F22 

F3  - (no  decomposition) 

Note  that  this  is  one  view  of  the  overall  function  of  the  valve;  many  such  views  can 
independently  exist. 

Here,  the  primary  function  of  the  valve  is  to  channel  the  liquid,  Fll,  and  to 
vary  the  liquid  flow  by  controlling  the  channel  opening,  F21.  For  the  valve  to 
operate  successfully,  its  design  needs  secondary  functions  such  as  preventing  leakage, 
F12,  and  holding  the  mechanism  that  varies  the  liquid  flow,  F22.  Figure  2.3  shows 
the  overall  functional  hierarchy  of  the  control  valve.  Each  node  describes  a specific 
functional  object  which  is  further  broken  down  into  subfunctional  objects. 

The  functional  hierarchy  in  Figure  2.3  does  not  show  how  the  subfunclionai 
objects  interact  to  define  an  aggregated  functional  object.  To  do  so,  we  need  a 
description  of  the  subfunction  interactions  as  shown  in  Figure  2.4.  This  description  is 
called  the  functional  interconnection  network  (FIN).  Figures  2.4a,  2.4b  and  2.4c 
show  how  the  subfunctions  of  FI,  F2  and  F (of  the  functional  hierarchy  of  Figure 
2.3)  interact,  respectively.  This  concept  will  be  further  explained  in  sections  3.2.2.2 

Similarly,  the  structure  of  the  valve  in  Figure  2.2  is  divided  into  suhstruc- 


51  - spindle 

52  - bearing  bush 

53  - sealing  bush 

54  - housing 

55  - threaded  bearing  bush 


Figure  2.3  Functional  hierarchy  of  the  flow  control  valve. 
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2.4a  Functional  interconnection  network  of  functional  object,  FI. 


2.4b  Functional  interconnection  network  of  functional  object.  F2. 


2.4c  Functional  interconnection  network  of  functional  object,  F. 


Figure  2.4  Functional  interconnection  networks  for  the  functional  objects  FI,  F2, 
and  F,  where  T,  V,  and  P are  the  values  of  the  torque,  liquid  volumes, 
and  position  of  the  spindle  transferred  between  functional  objects. 


The  structural  hierarchy  for  the  valve  is  shown  in  Figure  2.5.  This  hierar- 
chy is  derived  directly  from  Figure  2.2. 

Note  that  the  structural  and  functional  hierarchies  are  very  different.  This 
is  because  of  two  factors:  (a)  a structure  can  carry  out  more  than  one  function 
simultaneously,  e.g.,  the  spindle.  SI,  channels  the  liquid,  Fll,  and  varies  liquid  llow 
by  controlling  the  channel  opening,  F21;  and  (b)  many  structures  contribute  to  a 
function,  e.g.,  channeling  the  liquid,  Fll,  requires  the  spindle,  SI,  and  the  housing, 
S4. 


There  are  many  reasons  for  designers  to  prefer  this  structure-function 
dichotomy.  The  need  to  make  the  design  compact  and  to  reduce  the  cost  ns  well  as 
the  number  of  parts,  forces  designers  to  use  structures  that  carry  many  functions. 
On  the  other  hand,  manufacturing  constraints  and  reliability  requirements  typically 
dictate  the  assignment  of  several  structures  to  one  functional  task. 


From  the  database  requirement  specification  viewpoint,  the  structural  and 
functional  data  should  be  correlated  into  an  integrated  representation.  There  are 
three  pcssible  options  to  define  this  correlation:  (a)  assign  all  the  functions  carried  out 
by  the  structure  to  that  structure:  (b)  assign  all  the  structures  that  jointly  carry  out  a 
function  to  that  function;  and  (c)  have  a set  of  related  structures  and  functions. 

Using  option  (a)  to  model  the  flow  control  valve  (this  Is  the  traditional 
objectroriented  approach  of  assigning  functions  to  a structure),  the  design  hierarchy 
topologically  resembles  the  structural  hierarchy  shown  in  Figure  2.5.  The  design  con- 
sists of  these  objects: 


!{Sl},  {Fll,  F21,  FI,  F2,  F3}} 

m\  pi 

(SI},  (Fll.  F22,  FI,  F3}} 
{S5},  {F22}} 

!{S>.  {F» 


s 


Figure  2.5  Structural  hierarchy  of  the  flow  control  valve  if  Figure  2.2. 
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2.6b  Function  of  full  adder. 


Figure  2.6  Full  adder. 


On  the  other  hand,  by  using  option  (b),  the  design  hierarchy  has  a func- 
tional bias  where  all  the  structures  contributing  to  the  function  are  assigned  to  the 
function.  This  option  follows  the  design  philosophy  of  first  formulating  the  functional 
aspects  of  the  design  and  then  generating  the  structural  aspects  of  the  design.  The 
design  hierarchy  topologically  resembles  the  functional  hierarchy  shown  in  Figure  2.3. 
The  design  consists  of  these  objects: 


D21 

D22 

D26 

D27 

D28 


By  examining  the  two  sets  of  design  representations  above,  we  notice  that 
functional  objects  are  duplicated  in  option  (a),  and  the  structural  objects  are  dupli- 
cated in  option  (b).  This  duplication  is  not  eliminated  by  the  inheritance  paradigm 
purported  in  the  object-oriented  approach.  Also,  in  option  (a)  the  functional  model  is 
fragmented  and  forced  to  conform  with  the  structural  model  of  the  design:  in  option 
(b)  the  structural  model  is  fragmented  and  forced  to  conform  with  the  functional 
model  of  the  design.  In  effect,  the  functional  model  is  treated  as  second-class  infor- 
mation in  option  (a),  whereas  the  structural  model  is  treated  as  second-class  informa- 
tion in  option  (b).  The  only  solution  is  to  separate  structures  and  functions  as  dis- 
tinct aspects  of  a system,  capture  the  structural  and  functional  data  as  structural  and 
functional  objects,  and  correlate  these  objects  using  well-defined  associations. 

Option  (c)  preserves  the  structural  model  and  the  functional  model  of  the 
flow  control  valve  and  relates  these  models  by  an  interface  between  structural  and 
functional  objects,  called  interaction  objects.  This  dissertation  explores  option  (c)  to 
emphasise  the  representation  power  of  the  structure-function  paradigm. 


Once  the  structural  and  functional  objects  are  chosen,  they  are  precisely 
related  by  interaction  objects.  Interaction  objects  consist  of  a set  of  related  struc- 
tural objects,  functional  objects,  and  their  interactions.  Each  interaction  object,  D,  is 
represented  as  an  ordered  tuple: 

D:<set  of  structural  objects,  set  of  functional  objects,  interactions> 


A possible  configuration  using  option  (c)  is  shown  below: 


FI,  Fll,  F3},  {SI,  S4},  Il> 
F2,  F2l},  {SI},  I2> 

F12},  {S3},  I3> 

F22).  {S2,  SS,  S4},  14  > 


The  above  discussion  has  amply  illustrated  that  even  in  simple  designs  such 
as  a single  valve,  the  structure-function  correspondence  Is  complex.  Therefore,  to 
capture  the  requirements  for  engineering  designs,  it  is  absolutely  necessary  that  the 
system  specify  the  structure  and  the  function  independently  and  then  define  the 
structure-function  correspondences  through  interactions  as  shown  by  the  interaction 
objects.  Systems  that  support  the  encapsulation  principle  enforce  a 1:1  or  l:n  associ- 
ation between  structure  and  its  behavior.  One  side  effect  of  functional  encapsulation 
is  that  the  structural  and  functional  abstraction  hierarchies  are  forced  to  be  iso- 
morphic. In  normal  engineering  applications,  this  isomorphism  implies  that  every 
function  (or  group  of  functions)  has  its  unique  structural  configuration.  Although  it 
may  be  possible  to  construct  such  a design,  the  end  result  may  be  a bulky  and 
impractical  (unoptimized)  system.  This  is  seen  as  a serious  limitation  with  the  tradi- 
tional structure-oriented  philosophy  in  today's  data  models. 

The  second  example  is  the  full  adder.  Figure  2.6.  It  has  three  input  termi- 
nals X,  Y,  Cm,  and  two  output  terminals  S and  C0VT,  Figure  2.6a.  It  takes  two 
binary  numbers,  "x"  and  "y,"  and  a carry,  "carryin,"  from  the  previous  stage,  and  gen- 
erates their  sum,  "s,"  and  carry,  "carryout,"  respectively,  Figure  2.6b. 


The  FULL-ADDER  is  composed  of  the  ADD-Circuit,  SI,  and  the 
CARRY-circuit,  S2.  The  ADD  circuit  in  turn  has  2 EXCLUSIVE-OR  gates,  Sll 
and  S12,  and  the  CARRY-circuit  has  three  AND  gates,  S21,  S22,  and  S23,  and  one 
OR  gate,  S2-i.  The  structural  hierarchy  is  shown  in  Figure  2.7.  Each  node  of  the 
hierarchy  represents  a structural  object  of  the  adder  design  and  it  (node)  is  composed 
of  the  interconnection  of  substructure!  objects.  The  interconnection  information 
among  substructure!  objects  is  shown  by  the  structural  interconnection  network 
(SIN).  The  SIN  of  the  CARRY-circuit,  S2,  is  shown  in  Figure  2.8a.  A canonical 
graph  notation,  where  substructure!  objects  are  nodes  and  interconnections  are  links, 
for  the  SIN  of  the  CARRY-circuit  is  shown  in  Figure  2.8b.  Each  node  in  the  struc- 
tural  hierarchy  (except  the  leaf  nodes)  has  its  own  SIN.  The  structural  interconnec- 
tion network  is  discussed  in  subsection  3.2.I.2. 

The  functional  hierarchy,  Figure  2.9,  of  the  FULL-ADDER  is  similar  to  the 
structural  hierarchy  of  Figure  2.7.  In  this  design,  a functional  object  can  be  assigned 
to  a unique  structural  object,  as  there  is  a 1:1  correspondence  between  structure  and 
function.  The  design  hierarchy  topologically  resembles  either  the  structural  or  the 
functional  hierarchies,  as  shown  below: 

Dl:  < FULL-ADDER,  sum,  I> 

D2:  <ADD_Circuit,  add,  U> 

D3:  < CARRY-Clrcuit,  carry,  I2> 

Dl:  <EX-OR,  ex-or,  I3> 

D5:  <AND,  and,  I4> 

D6:  <OR,  or,  I5> 

This  example  shows  that  aggregation  of  structures  and  functions  is  essential 
in  presenting  engineering  systems.  The  ADD-circuit  is  the  aggregation  of  the  two 
EX-OR  gates  connected  together  in  a specific  manner,  similarly  the  CARRY-circuit 
is  the  aggregation  of  four  other  logic  gates,  and  the  FULL-ADDER  is  the  aggrega- 
tion of  the  ADD  and  CARRY  circuits.  Similar  abstractions  apply  for  the  functional 
objects  in  Figure  2.9.  The  components  of  a structural  object  are  connected  together 
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EX-OR 

(S11) 


AND  AND  AND  OR 

(S21)  (S22)  (S23)  (S24) 


AND  (S21) 


AND  (S23) 


2.8a  Structural  interconnection  network  of  carry  circuit. 


S24 


of  the  carry  circuit  in  Figure  2.8a. 
are  Rl,  R2.  R3,  R12,  and  R23. 


The  inter- 


Flgure  2.8 


(F11)  (F12)  (F21)  (F22)  (F23)  (F24) 


Figure  2.1 


only  by  their  interfaces  (see  Figure  2.8a).  Similarly,  the  functional  components  of  an 
object  interact  only  by  their  input  and  output  variables.  These  abstractions  are  dis- 
cussed in  Chapter  4. 

Through  the  above  examples  certain  points  become  obvious. 

(a)  In  most  cases,  there  is  no  1:1  correspondence  between  structure  and  function. 
Hence,  they  should  be  treated  ns  separate  objects  and  then  coupled  together  in 
an  interaction  object. 

(b)  Both  structure  and  function  are  decomposable  into  substructures  and  subfunc- 
tions: this  decomposition  is  not  symmetric  in  the  two  domains.  Object  decom- 
position can  be  applied  to  any  desired  level  of  detail,  depending  upon  the 
designer's  objectives.  At  this  point  it  should  be  noted  that  functional  decompo- 
sition of  complex  systems  is  not  easy  and  decomposition  techniques  vary  across 
domains. 

(c)  Abstraction  of  structure  (function)  primarily  involves  a clustering  of  substruc- 
tural  objects  (subfunctional  objects),  so  that  they  interact  through  their  inter- 
faces (input-output  variables).  Higher-level  objects  hide  the  details  of  structure 
(function)  of  the  lower-level  objects. 

(d)  A structure  or  function  may  be  composed  from  sets  of  similar  components  as  in 
the  CARRY-circuit  with  three  AND  gates.  Figure  2.7.  Each  instance,  however, 
has  a specific  role  and  meaning  in  the  design.  During  circuit  simulation,  the 
AND  gates  will  have  different  input-output  values  at  any  given  time. 

2.4  Definitions 

A system  is  a representation  of  a real  world  engineering  application  we 
wish  to  model  and  consists  of  a related  set  of  structural  objects,  functional  objects, 


and  interaction  objects. 


A functional  object  specifies  the  behavior  of  an  engineering  application 
either  declaratively  or  by  generating  a response  set  for  a given  set  of  inputs,  or  both; 
and  abstracts  subfunctional  objects  to  a single  abstract  functional  object.  A func- 
tional object  receives  the  input  stimulus  (i.e.,  input  variable  values)  to  the  system  and 
computes  the  next  state  of  the  system.  It  is  alternately  called  the  reactive  data 
describing  the  behavioral  properties  of  the  system. 

A structural  object  is  the  physical  structure  or  logical  configuration  of  an 
engineering  system.  It  defines  the  static  properties,  the  current  state  of  the  system, 
and  how  components  are  topologically  connected  together  in  an  overall  system.  The 
structural  object  is  alternately  called  passive  data  describing  the  structural  properties 
of  the  system.  A structural  object  is  expressed  in  terms  of  structural  features,  where 
each  feature  is  a unit  of  information  that  describes  the  physical  attributes  needed  for 
either  design,  simulation,  or  manufacture.  The  features  of  a structural  object  are  its 
state  variables,  component  description,  interface  among  components,  and  external 
geometric  features.  Features  are  described  in  terms  of  characteristics.  For  example, 
the  features  of  a spindle  (of  a flow  control  valve)  consists  of  Step-1,  Step_2,  Step_3, 
Key,  and  Passage.  The  characteristics  for  Step_l  arc  Us  length  and  diameter. 
Features  can  be  nested,  e.g„  the  Key  is  contained  in  Step-1,  and  Passage  is  contained 
in  Step_2,  see  Figure  2.10. 

An  interaction  object  models  the  relationship  between  structural  and  func- 
tional objects.  It  has  a twofold  purpose:  (a)  to  specify  the  structural  objects  that  arc 
updated  by  functional  objects;  and  (b)  to  relate  the  appropriate  features  of  the  struc- 
tural object  to  the  functional  objects. 

State  variables  are  a special  type  of  feature  of  a structural  object.  They 
are  a set  of  independent  variables  that  completely  describe  the  system  during  simula- 
tion. Together  with  the  input  variables,  they  uniquely  determine  the  next  state  of 
the  system.  A change  of  one  or  more  state  variables  constitutes  a state  change  of  the 
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system.  The  state  variable  values  are  stored  in  the  structural  object  and 
the  functional  objects  for  computing  the  next  state  of  the  system.  At  any  instant, 
the  state  of  the  structural  objects  represents  a "snap  shot"  of  the  system. 

State  transfer  function  of  a functional  object  takes  input  variable  values 
(stimulus)  from  (a)  other  functional  objects  or  the  user,  and  (b)  the  current  state  of 
the  structural  object  to  generate  the  new  state  of  the  structural  object.  Output  func- 
tion of  a functional  object  takes  the  current  state  variables  (and  inputs)  and  gen- 
erates the  output  variables  of  the  functional  object.  The  state-output  function  of  a 
functional  object  (a)  generates  output  variable  values  from  Input  variable  values  to 
the  functional  object,  and  (b)  updates  the  system  state.  It  consists  of  the  state 
transfer  function  and  the  output  function  of  the  functional  object. 

An  activation  instance  is  an  instance  (i.e.,  an  active  process)  of  a functional 
object  with  its  own  set  of  variable  values  drawn  from  structural  objects  and/or  other 
functional  objects.  There  can  exist  more  than  one  activation  instance  for  a func- 
tional object  at  a given  time. 

The  firing  of  an  activation  rule  generates  an  activation  instance  for  the 
functional  object.  This  rule  triggers  only  when  all  the  relevant  input  variable  values 
to  the  functional  object  are  present  and  the  preconditions  are  satisfied. 

The  firing  of  a deactivation  rule  terminates  the  execution  of  an  activation 
instance  of  a functional  object.  This  rule  triggers  only  when  all  the  relevant  output 
variable  values  of  the  object  are  computed  and  the  postconditions  are  satisfied.  The 
postcondition  can  include  any  external  asynchronous  event  or  a predetermined  time 
interval. 

A functional  object  is  in  the  active  mode  if  it  has  at  least  one  activation 
instance;  otherwise,  it  is  said  to  be  in  the  passive  mode. 

A partial  order,  P ™ (A,  <),  is  a set  A of  elements  ordered  by  an 
irreflexive,  transitive  binary  relation  < . A binary  relation  is  irreflexive  if  for  any  a f 
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A,  a < a is  false.  A binary  relation  is  transitive  if  for  any  a,  b,  c e A.  a < b,  b < c 
implies  a < c (BER87). 


THE  STRUCTURE-FUNCTION  PARADIGM 


3.1  Introduction 

This  chapter  discusses  in  detail  the  structure-function  paradigm  by  explain- 
ing the  structural  objects,  the  functional  objecls,  and  the  interaction  objects.  This 
discussion  is  followed  by  the  abstraction  of  structural  and  functional  information. 

3.2  Template  Description 

. A template  is  a generic  data  type  that  contains  the  basic  information 
needed  to  model  an  engineering  design  environment.  These  templates  aggregate 
information  to  describe  real  world  objects  at  a given  level  of  abstraction.  There  are 
three  types  of  templates;  structural,  functional,  and  interaction.  When  these  tem- 
plates are  instantiated  with  domain  specific  information,  they  correspond  to  the 
structural  object,  the  functional  object,  and  the  interaction  object,  respectively.  The 
interaction  templates  relate  the  structural  templates  and  the  functional  templates 
together.  This  section  describes  these  templates  in  detail. 

3.2.1  Structural  Template 

The  structural  template,  S,  is  a generic  data  type  that  holds  the  physical 
properties  of  an  engineering  domain.  A structural  object  is  a structural  template 
instantiated  with  design-specific  information.  This  instantiation  includes  both  the 
definition  of  the  attributes,  such  as  features,  state  variables,  and  assembly  relations, 
and  also  the  assignment  of  values  to  these  attributes.  Examples  of  structural  objects 


The 
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Is:  <Ps,  Cs, 


of  the  object.  These  features  are  either  atomic  (e.g.,  integer,  real,  boolean,  etc.), 
complex  (e.g.,  array,  list,  image,  etc.),  or  a geometric  description  (e.g.,  hole,  cylinder, 
block,  etc.).  Each  feature  has  a domain  of  legal  values.  Features  (excluding  state 
variables)  are  fully  defined  during  design  and  take  into  account  the  manufacturing 
constraints  of  the  object,  e.g.,  the  minimum  dimensions  of  the  spindle.  A state  vari- 
able, on  the  other  hand,  is  denned  during  the  design  phase  and  is  instantiated  during 
the  simulation  phase.  For  example,  when  designing  the  spindle  of  the  flow  control 
valve,  the  designer  defines  the  range  of  posable  spindle  positions,  such  as  0 to  360 
degrees  with  default  value  of  0 degrees;  only  in  simulation  (or  operation  of  the  valve) 
does  this  state  variable  take  a concrete  value,  say  45  degrees.  The  subset  of  the  cross 
product  (of  the  range)  of  state  values  defined  during  design  determines  the  set  of  pos- 
sible states  of  the  object  during  simulation. 

A set  of  primitive  operations,  such  as  insertion,  deletion  and  update,  or 
manufacturing  operations,  such  as,  drill,  mill,  grind,  file,  etc.,  are  stored  with  the  pro- 
perties of  a structural  object.  Therefore,  Ps  is  an  abstract  data  type  denoted  as 


where  V is  the  feature  description  and  0 is  a set  of  primitive  data  manipulations  or 
manufacturing  operations.  For  example,  the  state  variables  of  a spindle  in  the  flow 
control  valve  are  described  as 


As  another  example,  the  property  definition  for  a geometric  feature,  namely  hole,  is 


Ps  - {V,  0} 


position:  {0..3801  I 
flow-rate:  (real)  I 


position:  {0..360}  DEFAULT  0; 
flow-rate:  (real)  DEFAULT  0; 


diameter:  12mm; 
length:  8mm; 


material:  steel; 


Operations. 

} drill!); 

Components.  Cs.  The  component  Held,  Cs,  contains  a set  or  subcomponent 
declarations  of  SA . These  components  are  either  generalized  or  aggregated  to  an 
abstract  structural  object.  A generalized  object  consists  of  one  or  more  alternative 
substructural  objects.  For  example,  a Part-Feeding  device  in  a robotic  workcell  can 
be  either  a conveyor  belt  or  a kitting  tray.  An  aggregated  object  (complex  object), 
on  the  other  hand,  consists  of  one  or  more  substructure!  objects  that  are  physically 
connected  by  the  structural  interconnection  network  (SIN).  (This  dissertation  focuses 
on  complex  objects.)  Each  element  of  Cs  consists  of  a name  and  an  associated  set  of 
external  features,  Es,  of  the  component  object.  No  information  on  the  internal 
features,  Is,  of  the  component  object  is  stored  in  the  parent  complex  object. 

The  external  features  of  the  components  in  Cs  (a)  describe  the  interactions 
among  the  component  objects  by  the  SIN,  (b)  represent  levels  of  abstraction  where 
details  (internal  features)  of  the  component  are  hidden  from  the  complex  object,  and 
(c)  provide  modularity  in  design  by  insulating  a complex  object  from  changes  to  the 
interna]  features  of  its  components. 

Assembly  relations.  Rs.  The  assembly  relation  field  of  the  structural  tem- 
plate, SA , describes  the  connection  and  the  constraints  among  the  external  features 
of  the  components  that  form  a complex  object.  These  relationships  together  with  the 
elements  of  Cs  define  the  SIN  of  a complex  object. 

The  relationships  among  substructure!  objects  are  defined  in  the  parent 
object  because  these  relationships  exist  if  and  only  if  the  components  are  aggregated 
to  form  a higher-level  object.  For  example,  it  is  meaningful  to  describe  the  relation- 
ships among  the  spindle,  housing,  and  the  bushings  only  if  they  make  up  an  aggre- 
gated structure,  in  this  case,  a flow  control  valve.  Hence,  deletion  of  an  aggregated 


>lt  B.  The  relation  R,  is  repres 
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where  AB0VE1,  ABOVE2,  and  CLAMP  are  the  labels  of  the  constraint  relationships 
among  the  external  features  of  the  components.  If  the  components,  i.e.,  CS1,  CS2, 
CS3,  or  B,  used  in  the  assembly  are  updated,  the  functional  hierarchy  (which  is  a 
partial  ordering  of  assembly  operations,  i.e.,  an  assembly  plan)  checks  if  the  con- 
straint relations  are  violated  and  takes  the  relevant  action.  The  constraint 
specilicauon  system  is  described  later.  The  actual  physical  relationship  among  the 
external  features  of  CS1,  CS2,  CS3,  and  B are  generically  represented  by  the  func- 

When  the  external  features  are  distinguished  into  input-output  sets,  the 
assembly  relation  is  ordered  by  the  input  and  output  external  features.  Now,  an 
assembly  relation  is  defined  as 

Us  =r«<fo(C®,);5/(CS;)>  (invariant_3.2.2) 

The  assembly  relation  Rs  is  an  ordered  pair  of  sets.  The  first  set  contains 
the  output  external  features  of  the  substructure!  object  CSj  and  the  second  set  con- 
tains the  input  external  features  of  the  substructure!  object  CSj.  More  than  one 
object  can  participate  in  each  set;  therefore,  a 1:1,  l:n,  or  n:m  relationship  is  possible. 
This  representation  is  well-suited  for  representing  logic  circuits. 

3,2.2  Functional  Template 

The  second  component  of  the  SF  paradigm  is  the  functional  template  which 
models  the  behavior  of  the  structural  object.  The  functional  template  is  a generic 
data  type  that  holds  the  reactive  data  of  an  engineering  domain.  A functional  object 
is  a functional  template  instantiated  with  active  design  specific  information.  It 
represents  (a)  the  relationship  between  the  input  and  output  variables  of  the  func- 
tional object  or  consistency  conditions  in  terms  of  constraints,  and  (b)  the  composi- 
tion of  the  functional  object  from  subfunctional  objects.  A set  of  these  functionai 


objects  represents  the  overall  object  behavior  of  an  engineering  domain.  This  section 
presents  a detailed  discussion  of  a functional  template. 

A complex  functional  object  is  composed  of  other  functional  objects  in  a 
well-defined  manner.  Functional  objects  are  arranged  in  a DAG  where  lower-level 
objects  are  primitive  and  detailed  descriptions  of  the  domain,  and  higher  level  objects 
are  abstract  and  overall  descriptions  of  the  domain.  With  this  representation,  func- 
tional knowledge  is  stored  at  different  levels  of  abstraction. 

To  be  suitable  for  diverse  applications,  a functional  template  should 
represent  two  distinct  types  of  information.  First,  it  should  tell  the  external  world 
what  it  can  do,  i-e.,  its  functional  specification.  Second,  it  should  model  the  reactive 
aspects  of  the  object  by  responding  to  inputs,  i.e.,  its  behavior.  Functional 
specification  information  is  important  for  (a)  the  classification  of  the  appropriate 
component  during  design  based  on  its  characteristics  (e.g.,  the  rated  revolution  per 
minute,  the  rated  pressure,  and  output  flow  of  a hydraulic  pump  are  used  when  con- 
structing a hydraulic  circuit);  and  (b)  the  planning  phase  when  tasks  are  broken  down 
into  subtasks  and  each  subtask  is  assigned  to  a specific  manufacturing  process. 
Behavioral  information,  on  the  other  hand,  is  important  during  design  simulation 
where  each  object  responds  to  input  stimulus  from  the  environment. 

The  functional  template,  F,  is  defined  along  the  same  lines  as  the  structural 
template.  A functional  template  has  two  components-thc  external  features,  Ef,  and 
the  internal  features,  If,  and  is  defined  as  F:<Ef,  If>. 

3.2,3. 1 External  features.  Ef 

External  features  (of  a functional  object)  are  used  in  functional  object 
interactions  and  for  specifying  the  behavior  of  a functional  object.  More  precisely, 
the  external  features  of  an  object  describe  its  functional  specification  and  its 
(object’s)  input  and  output  variable  sets. 


Input  variables.  INf.  and  output  variables.  OUTf.  These  variables  receive 
data  values  from  the  external  environment  and  transmit  data  values  to  the  external 
environment.  Each  variable  is  associated  with  a domain:  these  domains  may  be  sim- 
ple, such  as  integers,  strings,  or  boolean,  or  may  be  complex,  such  as  arrays,  lists, 
events,  or  other  objects  themselves.  These  variables  are  represented  as 


Functional  specification.  FS.  The  functional  specification  or  a functional 
object  states  its  capabilities  without  describing  how  the  details  of  these  capabilities 
are  carried  out.  Functional  specification  is  represented  by  a conjunction  of  capabili- 
ties where  each  capability  states  an  operational  feature  of  the  object.  For  example, 
the  capabilities  of  a hydraulic  pump  are  its  rated  efficiency,  noise  level,  pressure 
range,  rated  speed,  and  liquid  compatibility.  The  functional  specification  of  a variable 
vane  hydraulic  pump  is  denoted  as 

(SET  variable_vane_hydraulic_pump 
(Efficiency:-  ((HIGH))), 

(Pressure:-  ([2000]pa)j, 

(liquid-Compatibility:-  ((OIL,  WATER])), 

(Speed:-  (|800..1800]rpm))) 

Each  capability  consists  of  a capability  label  and  a qualifier,  e.g.,  the  capa- 
bility (Speed:-  ((800..1800]rpm)  has  a capability  label  Speed  and  a qualifier 
[800..1800]rpm.  These  capabilities  help  the  designer  to  cluster  functional  objects 
with  similar  functionality,  to  retrieve  designs  (or  subdesigns)  that  meet  some  func- 
tional criteria,  and  select  alternative  functional  objects  that  have  similar  functional 
capabilities  but  different  operational  details.  The  different  types  of  capabilities  and 
algorithms  for  clustering  designs  on  their  functional  specifications  are  given  in  Cor- 
nelio  and  Navathe  [COROOb],  The  role  of  functional  specifications  in  integrating  pro- 
grams is  described  in  Chapter  6 of  this  work. 


3.2.2.2  Internal  features.  If 


The  internal  features,  If,  consist  of  (a)  a state-output  function,  Pf,  that 
relates  the  input  variable  set  to  the  output  variable  set,  (b)  a set  of  subfunctional 
object  declarations,  Cf,  and  (c)  a set  of  connection  relations,  Rf,  between  these  sub- 
functional objects. 

State-Output  Function.  Pf.  The  state-output  function  of  a functional 
object  relates  the  inputs  to  the  outputs.  It  consists  of  two  parts:  the  state  transfer 
function  that  computes  the  new  state  from  inputs  and  the  current  state;  and  the  out- 
put function  that  computes  the  outputs  from  the  current  state.  It  is  either  (a)  a gen- 
eric procedure,  (b)  an  inputroutput  table  enumerating  all  legal  input-output  pairs,  (c) 
performance  graph(s)  relating  the  input  and  output  variable  sets,  (d)  a dynamic 
model  describing  the  behavior  of  an  engineering  system,  or  (e)  a constraint  which 
raises  a set  of  exceptions,  where  each  exception  will  execute  a specific  action.  The 
state-output  function  should  completely  describe  the  working  of  one  functional 
aspect  of  the  object  at  a specified  level  of  detail.  This  means  that  a state-output 
function  is  an  abstraction  of  the  behavior  of  its  subfunctional  objects  and  their  associ- 
ated connection  relations.  State-output  functions  higher  up  in  the  functional  hierar- 
chy describe  the  overall  object  behavior  in  abstract  terms,  whereas  those  lower  down 
in  the  hierarchy  describe  subcomponent  behavior  in  detail.  The  details  of  this 
abstraction  are  given  in  section  4.3. 

There  are  two  ways  to  specify  a state-output  function,  as  shown  below.  In 
the  first  specification,  the  state-output  function  receives  inputs,  INf,  from  other  func- 
tional objects  (stimulus)  and  then  updates  the  state  variables  from  the  structural 
objects.  The  state-output  function  uses  these  inputs  to  (a)  change  the  state  of  the 
object  by  updating  the  state  variables  and  (b)  compute  the  output  values  for  the 
functional  object.  To  compute  the  next  state,  a state-output  function  uses  a set  of 
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active  variables.  An  active  variable  is  defined  as  one  which  (a)  has  valid  values  only 
when  the  functional  object  is  active,  (b)  does  not  depend  on  its  past  values,  and  (c) 
helps  in  moving  an  object  from  one  state  to  another.  Active  variables  are  like  the 
local  variables  of  a procedure  in  terms  of  its  scope,  whereas  state  variables  (described 
earlier)  are  global  variables. 

The  state-output  function  is  represented  as 

INPUT:  INf 
BODY: 

State  Transfer  function:  Pfs(INf,  state  variables); 

Output  function:  Pfo(state  variables); 

OUTPUT:  OUTf 

In  the  second  specification,  the  state-output  function  receives  state  variable 
values  through  an  event-driven  mechanism  directly  from  the  structural  object.  The 
function  then  tests  the  state  variables  against  any  applicable  constraint.  If  the  con- 
straint is  satisfied,  no  action  is  taken;  otherwise,  exceptions  are  raised  based  on  the 
type  of  failure.  Each  exception  executes  a predefined  action  to  satisfy  the  constraint. 
The  complete  constraint  system  is  described  in  Chapter  5 of  this  work. 

The  state-output  function  is  defined  as 

INPUT:  (state-variables) 

BODY: 

TEST  condition: 

ACTION: 

OUTPUT:  (state-variables) 

Components,  Cf.  Components  are  either  generalized  or  aggregated  to  an 
abstract  object  (CORQOa].  Functional  generalization,  F—GEN,  of  a set  of  functional 
objects  Fl,  F2,  ....  and  Fn  to  a functional  object,  F,  denotes  that  F is  carried  out  by 
either  Fl,  or  F2, ...,  or  Fn  at  a greater  level  of  detail.  For  example,  the  functional 
object  OPERATE  is  specialized  to  either  FORM  leads,  TRIM  leads,  or  SOLDER 
leads  (of  an  electronic  component).  Each  subfunction  operates  on  a component  but 
specifies  the  operation  in  greater  detail. 


Functional  aggregation,  F-AGG,  of  a set  of  functional  objects  FI,  F2,  ... 
Fn  to  a functional  object,  F,  denotes  that  F is  carried  out  by  FI,  F2,  ....  and  Fn 
together.  The  order  of  FI,  F2, ...,  and  Fn  is  specified  by  the  functional  interconnec- 
tion network  (FIN).  For  example  the  functional  object  CARRY  is  aggregated  from 
PICK,  MOVE,  and  PLACE,  i.e„  in  order  to  CARRY  an  object,  first  it  is  PICKed 
up,  then  it  is  MOVEd  from  its  initial  position  to  its  destination,  and  then  it  is 
PLACed  in  its  final  position.  Equivalence  conditions  for  F-AGG  between  the  parent 
object  and  the  set  of  components  is  given  in  chapter  4. 

The  subfunctional  objects  are  defined  independently  and  interact  only  by 
their  external  features.  When  two  (or  more)  subfunctional  objects  interact,  the  out- 
put variable  values  of  a subfunctional  object  are  passed  up  to  its  parent  object,  which 
then  determines  the  appropriate  subfunctional  objects)  to  receive  the  variables  as 
inputs.  Therefore,  only  the  interface  description,  i.e.,  the  input-output  variable  sets, 
of  each  subfunctional  object  need  to  be  stored  with  the  parent  functional  object,  SF. 

The  subfunctional  object  description,  Cf,  of  a functional  object,  SF,  is  writ- 

Cf  = (c  | c — component_name.external-features} 

Storing  the  subfunctions,  Cj , in  the  parent  functional  object,  SF,  has  many 
benefits:  (a)  it  describes  the  overall  system  behavior  in  terms  of  component  behavior: 
(b)  it  represents  different  levels  of  abstraction  of  functional  knowledge;  (c)  it  hides  the 
details  of  the  subfunctional  behavior  from  the  overall  object  behavior;  and  (d)  it  pro- 
vides modularity  in  modeling  the  dynamic  properties  of  a domain  by  insulating  a 
composite  object  from  changes  in  the  internal  features  of  its  components. 

Connection  Relations.  Rf.  Connection  relations  connect  together  the 
input-output  variable  sets  of  the  aggregated  subfunctional  objects  to  form  the  func- 
tional interconnection  network  (FIN)  of  the  complex  functional  object.  These  rela- 
tions do  not  possess  any  functional  power,  but  they  control  the  flow  of  variable 


values  between  objects,  and  therefore  the  invocation  sequence  of  subfunctional 
objects.  On  the  other  hand,  generalized  subfunctional  objects  are  alternative 
definitions  of  the  abstract  object  and  are  not  connected  to  each  other. 

Connection  relations  transfer  data  values  between  objects  by  connecting 
cither  one  output  variable  to  one  input  variable,  or  one  output  variable  to  many 
input  variables,  or  many  output  variables  to  one  input  variable.  There  are  six  kinds 
of  connection  relations:  sequence,  broadcast,  conditional,  repeating,  merge,  and 
meet.  The  sequence,  conditional,  and  repeating  connection  relations  correspond  to 
the  three  well-accepted  programming-language  control  structures.  The  broadcast, 
merge,  and  meet  connection  relations  are  used  in  distributed  systems  with  multiple 
active  processes.  These  relations  form  the  basic  set  from  which  other  relations  can 
be  constructed.  These  connection  relations  are  fully  described  in  section  3.6.  A con- 
nection relation,  R/t  is  represented  as 

R,  ={r/  | r/  -type< boolean-condition,  CSj.OUT,,  CSj.IN,>} 
where  Rr  is  a set  of  relations,  such  that  "type"  is  one  of  the  six  connection  relation 
types  stated  above,  "boolean-condition"  selects  the  external  features  to  transmit  (to 
send  or  receive)  data  values,  CS/.OUTf  and  CSj.IN ) are  the  output  variables  of 
components  CS,  and  the  input  variables  of  component  CSj,  respectively. 

3.2.3  Interaction  Template 

The  interaction  template.  D,  is  a generic  data  structure  that  models  the 
coupling  between  the  structural  objects  and  the  functional  objects  and  describes 
equivalences  between  multiple  representations  or  views  of  an  object.  An  interaction 
object  is  an  interaction  template  instantiated  with  mapping  information  between 
structural  objects  and  functional  objects.  The  structural-functional  relationship  can 
be  either  1:1,  l:n  or  n:m.  For  example,  referring  to  section  2.3,  the  interaction  object 
for  the  Adder  design  in  Figure  2.6  maps  one  structural  object  to  one  functional 


object;  the  interaction  object,  Dll,  for  the  flow  control  valve  in  Figure  2.2  maps  one 
structural  object,  spindle,  SI,  to  many  functional  objects,  Fl,  F2,  F3;  similarly,  the 
interaction  object,  D21,  maps  one  functional  object,  channel  liquid,  Fll,  to  many 
structural  objects,  SI  and  S4;  also,  the  interaction  object,  D31,  maps  many  structural 
objects  to  many  functional  objects. 

In  general,  the  interaction  object,  D,  relates  a set  of  structural  objects,  S,  to 
a set  of  functional  objects,  F,  by  an  interaction  description,  I,  and  is  defined  as 
D:<S,  F,  I>. 

3.2.3.1  Scope  of  interaction  object 

Unlike  the  structural  and  the  functional  objects  which  primarily  describe 
abstraction  relationships  among  similar  object  types,  the  interaction  object  estab- 
lishes (a)  relationships  between  structural  and  functional  objects,  and  (b)  equivalences 
between  objects  with  multiple  representations.  The  scope  of  the  structure-function 
correspondence  is  defined  by  the  set  of  structural  objects,  S,  and  the  set  of  functional 
objects,  F.  The  interaction  mappings  are  defined  over  the  parameters  of  these 

The  set  of  structural  objects  is  represented  as 
S — {s  |s  = structure-name} 

The  set  of  functional  objects  is  represented  as 
F “ {f  I f = function-name} 

3.2.3.2  Interaction 

The  interaction,  I,  of  an  interaction  object  holds  the  structural-functional 
mappings  between  elements  of  S and  F described  above.  The  mappings  are  object 
mapping  and  interna]  feature  mapping. 


Object  association  mapping,  Ml.  As  stated  in  section  2.5,  the  Ml  mapping 
relates  the  structural  and  the  functional  objects.  The  Ml  mappings  are  used  to  define 
the  structural  scope  of  functional  objects),  i.e.,  the  structural  objects  associated  with 
the  function,  or  to  define  the  functional  scope  of  structural  object(s),  i.e..,  functional 
objects  associated  with  the  structure. 

The  Ml  mapping  is  represented  as  a set  of  tuples  such  that 
Ml  = {ml  | ml  — <F(,  Sj> } 

where  F,  and  Sj  are  the  functional  objects  and  the  structural  objects,  respectively. 

During  structure-function  interaction,  a set  of  structural  objects  are  bound 
to  a set  of  functional  objects.  This  binding  is  based  on  the  information  in  the  Ml 
mapping.  A structural  object,  Sj,  is  bound  to  an  activation  instance  of  the  func- 
tional object,  Fj,  only  if  there  exists  a tuple,  ml,  in  the  Ml  mapping  such  that  ml  - 
<Fi,S,>. 

The  Ml  mapping  can  contain  explicit  information  on  the  mapping  between 
the  external  features  of  the  structural  and  functional  objects,  as  shown  below: 

Ml  — {ml  | ml  — <F,.Ef,  Sj.Es>} 

where  F,.Ef  are  the  external  features  of  a functional  object,  and  F,-,  and  Sj. Es,  arc 
the  external  features  of  a structural  object,  Sj. 

Internal  feature  mapping.  M2.  As  stated  in  section  2.5,  the  M2  mapping 
relates  the  internal  features  of  the  structural  and  the  functional  objects.  The  M2 
mapping  is  used  to  read  state  variables  from  the  structural  objects  to  the  functional 
object  and  to  write  the  state  valuable  changes  back  to  the  structural  objects. 

The  M2  mapping  is  represented  ns  a set  of  tuples  such  that 
M2  = {m2  | m2  - <F,.Pfs,  S,.Cv>} 

where  F,-.Pfs  is  the  state  transfer  function  of  a functional  object,  F,,  and  Sj. Cv  is  a 
feature  of  a structural  object,  Sj. 


During  structure-function  interaction,  the  state  of  the  system  is  updated 
due  to  an  input  stimulus  from  the  external  world.  The  state  of  the  structural  object, 
Sj,  is  updated  by  a functional  object,  F,,  only  if  (a)  Sj  is  bound  to  Ft  through  the 
Ml  mappings  (discussed  earlier),  and  (b)  for  the  feature,  cv  e Cv  in  Sy,  and  a state 
transfer  function  Pfs  of  F,,  there  exists  a tuple,  m2,  in  the  M2  mapping  such  that 
m2  - CF.Pfs,  S,-.cv>. 

When  a structural  object  satisfies  conditions  (a)  and  (b)  above,  it  is  said  to 
be  in  the  receiving  mode;  otherwise  it  is  said  to  be  in  the  passive  mode. 

■1.3  Structure-Function  Interaction 

3.3.1  introduction 

The  latter  part  of  the  previous  section  described  the  Ml  and  M2  mappings 
between  structural  and  functional  objects.  The  Ml  mapping  defines  the  interaction 
types  between  structures  and  functions,  whereas  the  M2  mapping  is  used  for  updatr 
ing  system  state.  This  section  describes  the  different  types  of  Ml  mappings. 

3.3.2  Interaction  Types 

By  treating  the  structural  objects  and  the  functional  objects  as  data,  i.o.,  as 
complex  objects,  the  interaction  between  them  can  be  broadly  classified  by  their  type 
and  degree  of  interaction.  There  are  four  basic  (structure-function)  interaction  types: 

3.3.2.1  Interaction  type  111 


The  structure-function  correspondence  is  1:1.  The  structural  description  is 
isomorphic  to  the  functional  description.  Here,  a functional  object  updates  the  state 


variables  of  only  one  structural  object,  and  the  state  variables  of  a structural  object 
are  updated  by  only  one  functional  object.  The  Ml  mapping  is  denoted  as 
Ml -{m,,-  |m„=<Fi,Si>} 

where  Fi  and  Si  arc  singletons.  This  mapping  type  is  called  identity  relationship. 
3.3.2.2  Interaction  type  121 

The  structure-function  correspondence  is  l:n.  Here,  the  state  variables  of 
one  structural  object  are  updated  by  more  than  one  functional  object.  There  are  two 
classes  of  l:n  structure-function  correspondences  in  this  interaction  type. 

0)  The  structure  supports  all  the  functions  simultaneously.  For  example, 
the  structural  object,  spindle,  is  associated  with  two  functional  objects,  control  chan- 
nel opening,  F21,  and  channel  liquid,  Fll,  respectively  p.e.,  the  state  variables, 
spindle's  position,  and  flow  rate  are  updated  by  F21  and  Fll,  respectively;  see  section 
2.3).  Also,  the  threads  on  a bolt  have  a set  of  associated  manufacturing  functions. 
The  functional  hierarchy  (DAG)  controls  the  sequence  (precedence)  of  the  functional 
objects.  The  Ml  mapping  is  denoted  as 

Ml  = {m„  | m,f  = <AND(F1,  F2, ....  Fj),  Si>} 
where  AND  associates  a set  of  functions  FI, ...,  Fj  to  the  structure  Si.  This  mapping 
type  is  called  S-F  aggregation  where  a structural  object  (spindle)  aggregates  the 
functional  objects  (control  channel  opening  and  channel  liquid). 

(ii)  The  structure  supports  alternative  functions;  the  appropriate  functional 
view  of  a structure  depends  on  the  functional  context  within  which  the  structure  is 
used.  At  any  time,  the  structural  object  is  associated  with  only  one  of  the  alterna- 
tive functional  objects.  A good  example  [KLE85]  is  a resistor  (structure)  that  can 
function  as  a load,  voltage  sensor,  currentrto-voltage  converter,  voltage-to-current 
converter,  etc.  The  Ml  mapping  is  denoted  as 

Ml  - {m,.-  | m„-  - <OR(Fl,  F2, ....  Fj),  Si>} 


where  OR  lists  the  set  of  alternative  functions  FI Fj  associated  with  the  struc- 

ture Si.  The  appropriate  function  is  determined  from  context  information,  described 
later.  This  mapping  type  is  called  S_F  generalization,  where  a structural  object 
(e.g.,  chair)  generalizes  the  functional  objects  (e-g.,  sit  on  and  stand  on). 

3.3.2.3  Interaction  type  f3l 

The  structure-function  correspondence  is  ml,  where  many  structures  are 
associated  with  a function.  There  are  three  classes  of  l:n  structure-function 
correspondences  in  this  interaction  type. 

(i)  The  functional  object  updates  the  stale  of  many  structural  objects.  All 
structural  objects  are  affected  by  the  input  to  the  functional  object.  For  example,  to 
support  the  spindle  requires  the  housing,  bearing  bush,  and  threaded  bearing  bush. 
The  Ml  mapping  is  denoted  as 

Ml  = {m„  | m„-  = <Fi,  AM>(S1,  S2 Sj)>} 

where  AND  specifies  the  set  of  structures,  Si,  ....  Sj,  associated  with  the  function  Fi. 
This  mapping  type  is  called  F—S  aggregation,  where  a functional  object  (support) 
aggregates  the  structural  objects  (housing,  bearing  bush,  and  threaded  bearing  bush). 

(li)  The  same  function  has  alternative  structural  implementations.  For 
example,  the  function  of  lifting  can  be  done  by  a robot's  arm,  fork  lift,  chain  pulley, 
or  a crane;  the  appropriate  structural  realization  of  the  function  depends  on  the 
structural  context  within  which  the  structure  is  used.  At  any  given  time  the  func- 
tional object  is  associated  with  one  of  the  alternative  structural  objects.  The  Ml 
mapping  is  denoted  as 

Ml  = {m„  | m„  = <Fi,  OR(Sl,  S2 Sj» 

where  OR  lists  the  set  of  alternative  implementations  SI,  S2,  ...,  Sj  of  the  function 
Fi.  The  correct  structure  is  determined  from  appropriate  context  information, 
described  later.  This  mapping  type  is  called  FJS  generalization  relationship,  where  a 
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functional  object  (lift)  generalizes  the  structural  objects  (robot's  arm,  fork  lift,  chain 
pulley,  and  crane). 

(iii)  Identical  structural  objects  with  the  same  behavior  are  used  in  different 
locations  in  the  design.  During  design,  it  is  common  to  use  standard  functional  blocks 
to  construct  complex  functions.  Hence,  each  functional  object  has  many  distinct 
structural  instances,  each  of  which  is  in  a different  state  at  a given  point  in  time. 
For  example,  logic  circuit  design  uses  standard  functional  blocks  such  as  AND,  OR, 
NOT,  etc.,  and  each  circuit  will  have  many  structural  instances  of  each  function. 
The  Ml  mapping  is  denoted  as 

Ml  - {m„  | m,,-  - <Fi,  ANY(S1,  S2 Sj)>} 

where  ANY  denotes  that  any  one  (or  more)  of  the  functionally  equivalent  structural 
objects,  SI,  S2, ....  Sj  is  bound  to  the  functional  object  Ft  at  a given  time. 

■1.3.2.4  Interaction  type  111 

The  structural-functional  correspondence  is  mm.  The  state  variables  of 
many  structural  objects  are  updated  by  many  functional  objects. 

The  m,,*  e Ml  mapping  for  this  type  is  represented  as 
mlf  = <AND(F„  ....  F„ ),  AND(S„  ...,  S,)> 

m„  = <AND(F OR(S, S,)> 

m,,-  - <OR(F„  ...,  F„),  AND(S„  ....  Sj)> 
where  Fit  ....  Fn  are  the  n functions  associated  with  the  j structures  ...,  Sj. 
Combinations  of  structures  or  functions  are  represented  by  the  AND  construct;  alter- 
native representations  of  structures  or  functions  are  represented  by  the  OR  construct. 
These  mapping  types  are  called  aggregation-aggregation,  F-S  aggregation- 
gencralization,  and  F_S  generalization-aggregation,  respectively. 

These  relationships  provide  the  flexibility  to  alternate  between  the  func- 
tional domain  and  the  structural  domain  during  design.  Consider  a database  of 
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structural  and  functional  objects  for  robotic  workcell  design.  To  design  a workcell 
for  assembling  circuit  boards,  first  this  overall  function  is  broken  down  into  subfunc- 
tions. Each  of  these  subfunctions  arc  matched  against  the  database  of  functional 
objects.  The  Ml  mappings  then  retrieve  the  set  of  structures  that  satisfies  these  sub- 
functions. Assume  that  "pi1*  chip,"  "test  chip,"  and  "insert  chip  in  board"  are  some 
of  the  subfunctions  of  a workcell.  Using  the  Ml  mappings,  the  pick  chip  function 
will  retrieve  a set  of  alternative  structures  used  for  picking,  the  test  chip  function  will 
retrieve  a set  of  alternative  chip  testing  hardware  and  bins  to  discard  faulty  chips, 
and  the  insert  chip  in  board  will  retrieve  a set  of  alternative  robots.  These  struc- 
tures, in  turn,  map  to  sets  of  functions  which  are  used  to  retrieve  structures,  and  the 
process  repeats.  Therefore,  by  alternating  between  structures  and  functions,  the 
workcell  designer  will  rapidly  build  a prototype  workcell  starting  from  a high-level 
functional  description.  A complete  example  of  using  structures  and  functions  to 
design  a workcell  is  given  in  Chapter  6. 

From  this  example  it  is  clear  that  the  Ml  mappings  arc  used  to  model 
design  knowledge  by  associating  alternative  structural  solutions  to  functional  tasks, 
and  by  associating  alternative  functional  uses  to  a specific  implementation.  Once  the 
components  of  the  design  are  known,  the  M2  mappings  relate  the  state  space  of  the 
design  to  the  function  of  the  system.  For  example,  the  state  variables,  position  of  the 
robot’s  arm,  and  status  of  chip  are  related  to  the  functions  pick  chip  and  test  chip, 
respectively.  The  Ml  and  M2  mappings  make  the  structural-functional  interaction  (a) 
flexible,  i.e.,  by  inserting  or  deleting  elements  in  these  mappings  the  correspondence 
between  design  structure  and  design  behavior  can  be  easily  changed;  (b)  modular,  by 
including  new  structures  and  functions  in  the  design  with  minimum  effort,  thus  pro- 
viding a base  for  rapid  prototyping  of  complex  systems;  and  (c)  having  multiple  views 
of  objects,  i.e.,  a structure  can  have  multiple  functional  views,  and  a function  can 
have  many  implementations. 


Interaction  Cycle  os  a Unit  of  Dynamic  Behavior  Modeling 


3.4.1  Introduction 

In  simulation,  the  schema  is  predetermined  by  the  simulation  model  (func- 
tional data)  and  the  physical  configuration  or  layout  of  the  design.  The  instances  of 
the  simulation  schema  are  generated  during  a simulation  run  where  a new  instance 
set  is  generated  for  each  run.  This  section  defines  a simulation  schema  and  shows 
how  the  structure-function  modeling  paradigm  supports  simulation.  Simulation  is 
based  on  the  interaction  cycle,  which  is  the  atomic  unit  of  structure-function 


3.4.2  Simulation  Schema 

The  simulation  schema  models  the  application  by  a set  of  structural 
objects,  functional  objects,  and  interaction  objects.  The  functional  hierarchy  models 
the  behavior  of  the  system  at  different  levels  of  abstraction.  The  structural  hierarchy 
models  the  physical  design  and  defines  the  state  variables  used  in  the  simulation. 
The  change  in  system  state  and  the  input  and  output  variables  to  the  system  are  also 
recorded  in  the  database  system  during  simulation.  The  interaction  between  the 
state  variables  and  the  functional  information  is  managed  by  a generic  algorithm 
called  the  interaction  cycle,  IC. 

Therefore,  a simulation  schema,  SIM,  is  a five-place  tuple,  denoted  as 
SIM  - <S,  F,  D,  DB(t),  !C> 

where  S is  the  set  containing  structural  information,  F is  the  set  containing  functional 
information,  D is  the  set  of  interaction  objects,  DB(t)  is  the  set  of  values  for  the  state 
variables  and  the  input-output  variables  of  the  functional  objects.  These  variable 
values  arc  the  run-time  extension  of  the  simulation  schema,  and  they  are  a function 


of  time  and  the  simulation  run  number.  The  interaction  cycle  (IC)  relates  S,  F,  D, 
and  DB(t)  in  a simulation.  The  next  subsection  discusses  the  role  of  IC  in  simulation. 

3.4.3  interaction  Cycle 

The  interaction  cycle  dynamically  exchanges  information  between  the 
structures  and  functions  to  (a)  update  system  state  when  inputs  are  applied  to  the 
system,  or  (b)  invoke  actions  when  the  system  reaches  a critical  state.  We  will  only 
analyze  case  (a);  case  (b)  is  discussed  briefly.  Case  (a)  is  handled  in  the  constraint 
specification  system  described  in  Chapter  5. 

The  IC  dynamically  selects  the  appropriate  structural  objects  during  simu- 
lation that  are  influenced  by  the  inputs  (to  the  functional  objects)  and  then  selects 
the  state  variables  of  these  structural  objects.  These  state  variables  are  updated  by 
the  functional  objects,  and  the  values  are  transferred  back  to  the  structural  objects. 
Simulation  consists  of  an  iterative  execution  of  interaction  cycles,  where  each  cycle 
updates  the  state  of  some  of  the  structures  of  the  system.  The  interaction  cycle  uses 
the  Ml  mapping  to  bind  structural  and  functional  objects  and  the  M2  mapping  to 
read  and  write  state  variables  between  the  structural  and  functional  objects. 

The  Ml  mapping  has  two  generic  operations  associated  with  it,  namely 
BIND  and  FREE.  The  BIND  operation  picks  out  a set  of  structural  objects  and 
binds  them  to  an  activation  instance  of  a functional  object.  The  FREE  operation 
releases  the  structural  objects  from  the  activation  instance  of  the  functional  object. 
The  M2  mapping  also  has  two  generic  operations  associated  with  it,  namely  GET 
and  PUT.  The  GET  operation  reads  the  current  state  variable  values  of  the  bound 
structural  object  for  the  activation  instance  of  the  functional  object;  the  PUT  opera- 


ral  object. 


To  explain  the  interaction  cycle,  the  definition  of  the  structural  object  How 
control  valve  SI,  the  function,  transmit  liquid  FI,  and  the  interaction  object  Dl, 
between  SI  and  FI  are  given  below. 


INTERNAL  FEATURES 
Ps:  /*  properties  */ 

Status:  {ON,  OFF}; 


1 lousing; 
Spindle; 
Sealing  Bush: 


DEFINE  FUNCTIONAL  OBJECT:  FI 
EXTERNAL  FEATURES 
INf:  in-flow,  Fhrcal; 

Torque,  Threal; 

OUTf:  out— flow,  Fo:real; 

INTERNAL  FEATURES 
Pf:  f-transmil.  /•  state_outi 

INPUT:  Fi; 

BODY:  Status  = f_t(Fi,  Ti.  Status) 

Fo-l 

OUTPUT:  Fo; 

Cs:  FI,  F2,  F3;  / 


DEFINE  INTERACTION  OBJECT:  D1 
SCOPE 

STRUCTURAL  OBJECTS:  SI; 
FUNCTIONAL  OBJECTS:  FI; 

INTERFACE 


END  INTERACTION  OBJECT:  Dl. 


3.  I.3.1  Simple  caw 

The  structure-function  cycle  is  based  on  the  mappinp,  Ml  and  M2,  and  the 
associated  operators,  BIND,  FREE,  GET,  and  PUT.  This  section  describes  the  cycle 
for  the  simple  case  where  (a)  Ml  does  not  use  selection  predicates,  i.e.,  every  struc- 
tural component  is  functionally  distinct,  and  (b)  the  structural  objects  do  not  directly 
activate  additional  functional  objects  in  the  interaction  cycle,  i.e.,  the  interaction 
cycle  is  not  structurally  driven.  Assume  as  starting  conditions  that  all  the  structural 
objects,  S,  are  in  the  passive  mode  and  the  functional  objects,  F,  do  not  have  activa- 
tion instances.  In  the  above  example,  the  functional  object,  FI,  "transmit  liquid,"  has 
no  activation  instances,  and  the  structural  object,  the  flow  control  valve,  SI,  is  in  the 
passive  mode  with  state  variable,  Status  = OFF.  When  an  input  stimulus,  input 
torque,  is  applied  to  the  system,  it  satisfies  the  preconditions  for  functional  object, 
FI,  thus  firing  the  activation  rule.  The  firing  of  the  rule  creats  an  activation  instance 
for  FI.  The  Ml  mappinp  (in  the  interaction  object,  Dl)  identify  that  the  structural 
object.  Si,  will  be  affected  by  the  input  to  FI,  and  the  BIND  operator  binds  SI  to 
the  activation  instance  of  FI.  The  M2  mapping  identifies  that  the  state  variable  (i.e., 
Status  — ON/OFF)  of  SI  will  be  changed  by  FI,  and  the  GET  operation  reads  the 


state  variable  value  "s 
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status  — OFF"  from  the  structural  object,  SI,  and  writes  it  to 
the  activation  instance  of  Fl.  The  state  transfer  function,  P_t,  or  Fl,  processes  the 
input  variable  (be.,  input  torque)  and  the  current  state  variable  value  (i.e.,  Status  — 
OFF)  to  generate  the  new  state,  i.e„  Status  = ON.  The  new  state  is  written  to  SI 
by  the  PUT  operator,  and  SI  is  released  by  the  FREE  operator.  The  output  func- 
tion, f,  computes  the  outputs  of  Fl  from  the  current  state  variable  value.  Status  = 
ON.  The  deactivation  rule  places  Fl  in  the  passive  mode.  This  is  one  complete 
cycle  of  the  function-structure  interaction.  Figure  3.1  shows  a generic  interaction 

3.-I.3.2  General  case 

For  the  general  interaction  cycle,  the  Ml  mapping  uses  the  selection  predi- 
cates (structural  context,  see  Chapter  6)  to  determine  the  appropriate  structural 
object  in  the  interaction  type  (iii)  of  section  3.3.2.3.  The  interaction  cycle  has  to  do 
two  additional  tasks:  (a)  know  the  set  of  structural  objects  that  were  in  the  receiving 
mode  in  the  previous  interaction  cycle;  and  (b)  pick  the  appropriate  set  of  tuples  in 
the  Ml  mapping  based  on  the  information  available  in  (a)  by  using  the  selection 
predicates. 

For  (a),  assume  that  in  an  interaction  cycle  the  structural  object,  S,,  is 
bound  to  a functional  object,  F, . At  the  end  of  the  cycle,  the  structural  object,  S., 
and  its  parent,  Sc,  are  passed  to  the  next  interaction  cycle  by  transferring  these 
objects  to  the  next  functional  object,  F,+l,  in  the  functional  DAG. 

To  perform  task  (b),  the  BIND  operator  determines  from  the  Ml  mappings 
if  the  functional  object,  Fi+„  belongs  to  interaction  type  (Hi)  of  section  3.3.2 .3,  such 
that  there  exists  an  element,  ml  < Ml,  where  ml  = <Fi+„  ANY(S„  ....  S„)>.  Let 
the  set  Mstmctp^  « 5,,  ....  S„ . The  BIND  operator  then  searches  for  a selection 
predicate,  fc( q,  r),  where  /,  = Sc,  q = S,  and  r e Mstructp^.  Now,  r is  the 
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M-structural  object  that  is  bound  to  the  functional  object  F(+,  in  the  next  interac- 
tion cycle. 

In  the  case  of  a structural  DAG  the  selection  predicate,  f(q,  r),  is  satisfied 
when  q =<  <Sc , > and  r £ Mslructp^. 

3.5  Rules  for  Structure-Function  Interaction 

This  section  gives  the  rules  necessary  to  successfully  carry  out  structure- 
function  interaction  described  in  the  previous  section.  The  rules  for  structure- 
function  interaction  are 

(a)  A structural  object  can  be  in  one  of  these  modes:  the  passive  mode,  when  its 
state  variables  cannot  change;  and  the  receiving  mode,  when  the  state  variables 
change.  Similarly,  a functional  object  can  be  in  one  of  these  modes:  the  pas- 
sive mode,  between  the  firing  of  the  deactivation  rule  and  the  activation  rule; 
and  the  active  mode,  between  the  firing  of  the  activation  rule  and  the  deactiva- 
tion rule. 

(b)  A structural  object  moves  from  the  passive  mode  to  the  receiving  mode  only  by 
a BIND  operation  executed  on  the  Ml  mappings  of  an  interaction  object.  In 
physical  terms,  this  means  the  physical  object  receives  an  input  stimulus. 

(c)  The  state  variables  of  a structural  object  can  be  updated  only  by  the  activation 
instance  of  the  functional  object  that  brought  it  into  the  receiving  mode.  This 
means  that  a physical  object  cannot  change  state  unless  it  received  an  input. 
For  example,  a robot  arm  cannot  initiate  or  terminate  motion  until  it  receives 
commands  from  the  controller;  or  a spindle  of  a flow  control  valve 
permits/inhibits  liquid  flow  only  if  input  torque  is  applied. 
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(d)  Only  the  functional  object(s)  that  brought  the  structural  object  into  the  receiv- 
ing mode  can  take  it  back  to  the  passive  mode.  This  rule  prevents  inconsisten- 
cies due  to  many  functional  objects  trying  to  independently  update  the  state. 

(c)  The  activation  rule  places  a functional  object  in  an  active  mode  by  generating 
an  activation  instance.  The  deactivation  rule  destroys  the  activation  instance  of 
a functional  object.  When  a functional  object  has  no  activation  instances,  it  is 
said  to  be  in  the  passive  mode. 

3.6  Connection  Relation  Types 

This  section  describes  in  detail  the  need  for  connection  relations,  the 
different  types  of  connection  relations,  and  how  they  help  in  aggregating  functional 
objects.  Connection  relations  relate  subfunctional  objects  to  constitute  overall  object 
behavior. 

The  connection  relations  described  here  are  more  complex  than  the 
behavioral  relationships  used  in  the  behavioral  schemas  for  transaction  modeling 
[BR082|.  In  transaction  modeling,  dynamic  information  are  descriptions  of  transac- 
tions, actions,  and  operations  on  the  static  data  (entities  and  relationships).  A tran- 
saction is  a high-level  specification  of  the  users’  requirements  and  consists  of  a list  of 
objects  (scope),  preconditions,  postconditions,  and  action  invocations.  An  action 
alters  the  static  data  by  using  one  of  the  primitive  database  operations,  such  as 
insert,  delete,  update,  etc.  Behavioral  relationships  define  control  abstractions  by 
relating  primitive  operations  to  higher-level,  composite  operations.  The  behavioral 
relationships  used  are  sequence,  conditional,  and  repetition.  There  is  no  interaction  of 
data  values  between  operations. 

Connection  relations,  on  the  other  hand,  provide  all  the  abstraction  power 
of  the  behavioral  relationships  used  in  transaction  modeling.  In  addition,  connection 


relations  relate  the  external  features  (input-output  variables)  of  the  functional 
objects,  thus  permitting  transfer  of  data  values  between  functional  objects.  This 
information  transfer  is  similar  to  the  communication  links  used  in  the  event  model  of 
King  and  McLeod  [KEx'82],  The  major  difference  between  connection  relations  and 
communication  links  is  the  connection  relations  have  the  capacity  to  selectively  route 
the  information  between  a set  of  functional  objects,  whereas  communication  links 
transfer  information  between  a pair  of  process  events. 

For  the  sake  of  conciseness  of  notation  (a)  the  word  object  means  functional 
object,  and  (b)  F,-.IN  and  F.  .OUT  represent  the  input  and  output  features  of  a func- 
tional object,  Fj,  respectively. 

There  are  six  primitive  connection  relation  types.  All  input-output  interac- 
tions between  functional  objects  can  be  composed  from  these  primitive  types. 

SEQUENCE:  Given  two  objects  F |,  and  F2,  an  output  variable  of  object 
F , is  connected  directly  to  an  input  variable  of  object  F».  The  output  data  from 
object  F,  is  transmitted  to  the  input  of  object  F.,. 

This  connection  relation  is  of  type  SEQ  and  is  expressed  as  SEQ<F,.OUT, 

FjJN>. 

CONDITIONAL:  An  output  variable  of  object  FA  is  connected  to  one 
input  variable  of  each  of  the  k objects  F„  ..,  Ft  in  set  B,  where  B is  finite.  The  con- 
ditional relation  transmits  the  output  data  of  object,  FA , to  the  inputs  of  one  of  the 
objects  in  set  B. 

This  connection  relation  between  objects  FA  and  F„  ...  Ft  is  of  type 
COND  and  is  expressed  as  CONDebooLcond,  FA  .OUT,  F,.IN, FK JN>,  where 
"booLcond”  is  a boolean  statement  that  selects  one  of  the  k objects  in  set  B. 

BROADCAST:  An  output  variable  of  object  FA  is  connected  to  one  input 
variable  of  each  of  the  k objects  F ]t ..,  F*  in  set  B,  where  B is  finite.  The  broadcast 


relation  transmits  the  output  data  of  object,  FA,  to  the  inputs  of  all  of  the  objects  in 
setB. 

This  connection  relation  between  objects  FA  and  F„  ...  Ft  is  of  type  ALL 
and  is  expressed  as  ALL-cF,  .OUT,  F,.IN,...,  FtJN>. 

REPEATING:  An  output  variable  of  object  FA  is  connected  to  one  input 
variable  of  each  of  the  k objects  (general  case),  F„  Ft  or  to  an  input  variable  of  a 
single  object  FB  (special  case).  For  brevity,  the  special  case  will  be  explained,  i.e., 
Fa  feeds  only  one  object  FB;  the  general  case  is  a natural  extension  of  the  special 
case.  The  repeating  relation  transmits  the  output  data  of  object,  FA , to  the  input  of 
the  object,  Fg,  a given  number  of  times  based  on  some  condition. 

This  connection  relation  is  of  type  WHILE  and  is  expressed  as 
WHILE<cond,  FA. OUT,  Fg.IN>  where  "cond"  determines  the  number  of  times 
object  Fa  transmits  the  output  data  to  object  Fg. 

MERGE:  The  output  variables,  one  from  each  of  the  k objects  F],  ...  Ft  in 
set  A,  where  A is  finite,  are  connected  to  an  input  variable  of  object  Fg.  The  merge 
relation  transmits  the  output  data  from  all  the  objects  in  set  A to  the  input  of 
object,  Fg. 

This  connection  relation  between  objects  F „ ...  Fk  and  Fg  is  of  type 
MERGE  and  is  expressed  as  MERGE<F,.OUT, ....  Ft.OUT,  F0JN>. 

MEET:  The  output  variables,  one  from  each  of  the  k objects  F,, ...  Fj  in 
set  A,  where  A is  finite,  are  connected  to  an  input  variable  of  object  Fg.  The  meet 
relation  transmits  the  output  data  from  one  the  objects  in  set  A to  the  input  of 
object,  Fg. 

This  connection  relation  between  objects  Fit  ...  F*  and  Fg  is  of  type 
MEET  and  is  expressed  as  MEET  < booLxond,  F,.OUT,  ....  Ft.OUT,  Fg.IN> 
where  'booLxond"  is  a boolean  statement  that  selects  one  of  the  k objects  in  set  A. 


As  a general  comment,  in  the  above  connection  relation  types  the  output  of 
an  object  is  transmitted  to  the  inputs  of  another  objects)  through  their  external 
features.  As  the  external  features  of  objects  are  related  at  the  parent  object,  all  out- 
put values  of  an  object  are  sent  to  the  parent  object,  which  decides  (by  using  the 
connection  relations)  on  the  input  variable  of  the  next  object  to  receive  these  inputs. 

This  chapter  discussed  the  SF  paradigm  in  detail.  The  next  chapter  shows 
the  abstractions  used  in  the  SF  paradigm  to  define  composite  structural  objects  and 
composite  functional  objects. 


CHAPTER  4 

ABSTRACTION  OF  COMPOSITE  STRUCTURES 
AND  COMPOSITE  FUNCTIONS 


4.1  Introduction 

This  chapter  focuses  on  two  topics-abstraction  of  composite  structural 

ing,  inserting,  and  deleting  composite  objects  arc  proposed. 

4.2  Structural  Abstraction 

This  section  formalizes  structural  abstraction  by  a set  of  invariants.  These 

generalized  to  define  directed  acyclic  graphs  (DAG)  of  composite  structural  objects. 
A set  of  data  manipulation  rules  for  structural  objects  based  on  the  invariants  are 

4.2.1  Invariants  on  External  Features 

The  external  feature  set  of  an  object,  SA , is  described  for  (a)  a primitive 
object,  i.e.,  an  object  with  no  substructure!  objects;  and  (b)  a complex  object  which 
is  composed  of  other  primitive  or  complex  objects. 

f(SP)  - {e  | e<&  mdSpKE, .,  /»>}  (invariont_4.2.1a) 

where  5p:<Es,  Io>  is  the  structural  definition  of  Sp. 


The  external  features  of  a complex  object,  SA , are  denoted  as 
£(s-t)£ (invi 


(invariant_4.2.1b) 


where  Cs  is  the  set  of  substructure!  components  of  SA , and  fnd  — •£  is  a function 
returning  the  external  features,  E,  of  any  object,  A.  Invariants  4.2.1a  and  4.2.1b 
together  constitute  the  structure/  composition  axiom. 

invariant  4.2.1a  states  that  the  set  of  external  features  of  a primitive  object 
is  directly  determined  from  the  object  definition.  Invariant  4.2.1b  states  that  the  set 
of  external  features  of  a complex  structural  object  is  the  subset  of  the  external 
features  or  all  its  substructure!  objects,  Cj  ( CjcCs ).  This  definition  is  recursive  and 
describes  how  a complex  object  is  constructed  from  its  components.  Intuitively,  the 
applicability  of  invariant  4.2.1b  can  be  seen  from  Figure  4.1.  Here,  the  structural 
object  SA  is  composed  of  three  substructural  objects  Cl,  C2,  and  C3.  The  set  of 
external  features  of  the  substructural  objects  is  given  by 
act.C2.C3  — u {{a,  b,  c},  {d,  f},  {e,  g}}  - {a,  b,  c,  d,  e,  f,  g} 

The  external  features  of  the  complex  object  SA  are  EsSa  — {a,  f,  g},  thus 
giving  EsgA  C ftsct.C2.c3*  83  stated  in  invariant  lb. 

The  external  features  for  an  object,  SA,  with  input  and  output  sets  are 
more  explicit,  as  shown  by  invariant  4.2.2  below. 


where  CS,-  « Cs  is  the  set  of  substructural  objects  of  SA ; and  £„(CS,)  and  £,(CS.) 
are  functions  that  return  the  output  features  and  input  features  of  substructural 
object  CS,,  respectively. 

Invariant  4.2.2  states  that  the  set  of  external  features  of  a structural  object, 
SA,  is  the  subset  of  the  inputs  and  the  outputs  of  all  its  components.  We  now 


«s-t)C  {^U^fHCS,)  U £0(CS,)  } 


(invarianL.4.2.2) 


Figure  4.1 


The  structural  object.  5, , is  < 
CX.  C2,  and  C3.  Rl  and  R2 
and  Cl,  C3,  respectively. 


tbstructural  objects. 


of  the  external 
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express  the  input  and  output  features  of  the  object,  S, , in  terms 
features  of  its  substructure!  objects.  The  input  features  of  SA  are 

Zl(sA ) £ 5((CS,)  (invariant_4.2.3a) 

The  output  features  of  SA  are 

MSa)  c S,)  (invariant_4.2.3b) 

Invariant  4.2.3a  states  that  the  set  of  input  features  of  a complex  object  is 
the  subset  of  the  input  features  of  its  components.  Invariant  4.2.3b  states  the  same 
condition  holds  for  the  outputs.  The  above  invariants  are  the  fundamental  properties 
for  building  structural  hierarchies  based  on  features. 

4.2.2  Feature  Preservation  invariant 

Invariants  4.2.1,  4.2.2,  and  4.2.3  are  inequalities  that  define  complex  struc- 
tural objects.  In  engineering  design,  however,  the  semantics  of  aggregation  is  clcsely 
tied  to  the  semantics  of  composition  [NAV90].  The  external  feature  preservation 
invariant  below  shows  the  relationship  between  (a)  the  interaction  of  components  and 
(b)  the  hierarchical  aggregation  of  the  component  objects  to  form  a parent  structural 

Let  QCSj)  be  the  external  features  of  OSj,  where  CSj  c Cs,  is  a com- 
ponent of  the  complex  structural  object,  SA.  Let  QSAj  be  the  external  features  of 
SA . Define  q(/i,)  to  be  the  external  features  of  the  objects,  CS,-  c Cs,  participating  in 
the  assembly  relationship,  R,.  These  quantities  are  related  as  shown  below: 

QS4)  U { ^ dCSj)  (invariant_4.2.4) 

Invariant  4.2.4  states  that  all  external  features  of  the  substructure!  objects  should 
either  appear  as  the  external  features  of  the  parent  structural  object  or  participate  in 
an  assembly  relation  between  the  components,  or  both.  This  condition  forms  a basis 
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for  hierarchical  abstraction  of  complex  structural  objects  by  their  external  features  as 
shown  in  the  following  example. 

From  Figure  4.1, 
flS„)-{a,f,g} 

r Ur;*R,  )-U{{6,  d},{c,  e}} 

-{W,c,e} 

%SA ) U {R  yRin(ff,  ) > - {a,  b.  c,  d,  e,  f,  g} 

^ «GSy) -U{{«,  4,  c}{d, /},{«,«}} 

- {a,  b,  c,  d,  e,  f,  g} 

Showing  that, 

QS^U^U^R,)  } _ cUiCi  f(CS,) 

As  a sketch  of  the  proof  for  invariant  4.2.4,  let  LHS  and  RHS  stand  for 
left-hand  side  and  right-hand  side  of  invariant  4.2.4,  respectively. 

To  prove  LHS  C RHS,  (a)  from  the  structural  composition  axiom,  i.e.,  by  invariants 
4.2.1a  and  4.2.1b,  we  have  ((SA ) C c ((CS;)-,  and  (b)  from  the  definition  of 
’/(It,),  the  external  features  that  participate  in  the  assembly  relationships  R,-  belong 
to  the  component  objects  CSj  e Cs.  Hence,  we  have  r Ur  ij(R,-)  } C ^ {( CS j). 

Taking  the  union  of  (a)  and  (b)  above, 

U^SJ.^U^R,)}  C cUc^(C5,)} 

This  implies  that 

SS^li^  u^R,)}  C JJ^CS,) 
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To  prove  RHS  C LHS,  assume  that  this  is  false;  then  there  exists  an  external  feature 
defined  on  a component  (a)  that  is  never  used,  and/or  (b)  that  is  not  used  in  the 
parent  object.  Case  (a)  is  ruled  out  because  of  the  external  features  definition,  given 
earlier.  The  only  plausible  explanation  for  case  (b)  is  there  exists  a DAG  of  struc- 
tural objects  where  a component  is  physically  shared  by  two  or  more  complex 
objects.  As  objects  are  decomposed  hierarchically,  we  eliminate  this  case. 

The  next  section  generalizes  invariant  4.2.4  to  handle  cases  where  a struc- 
tural object  is  shared  by  more  than  one  parent  complex  object. 

4.2.3  Structural  DAG 

Invariants  4.2.1  through  4.2.4  define  a strict  structural  hierarchy  (part-of 
hierarchy)  for  physical  objects.  Here  a component  can  have  only  one  parent  object 
[KIM87b).  For  generality,  this  restriction  should  be  removed  (KIM80]  to  represent 
physical  engineering  systems.  For  example,  an  electrical  power  source  supplies  power 
to  many  independent  electric  circuits.  If  each  circuit  is  modeled  as  a complex  object 
with  the  circuit  elements  as  component  objects,  the  power  source  is  a common  sub- 
part  of  each  circuit  and  is  shared  by  all  circuits.  Similar  examples  arc  found  in 
modeling  hydraulic  circuits  with  shared  reservoirs,  in  modeling  homes  with  shared 

To  represent  the  general  case,  the  above  invariants  are  modified  such  that 
the  complex  object,  SA , on  the  left  hand  side  of  each  of  these  invariants  is  replaced 
by  a set  of  objects.  S.  For  example,  invariant  4.2.4  is  written  as 

«s)  u <B  IMIW) } - c sya  SfiSj)  (4.2.4-) 

A component  object.  CS. . can  have  several  parents,  allowing  a DAG  of  structural 
objects. 
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To  show  that  invariant  4.2.4'  is  true,  the  proof  proceeds  as  for  invariant 
4.2.4.  However,  case  (b)  of  RHS  C LHS  of  invariant  4.2.4  does  not  arise  as  the  struc- 
tural object,  SA,  is  replaced  by  a set  of  structural  objects,  S.  Therefore  4.2.4'  holds. 

4.2.4  Rules  for  Manipulating  Structural  Objects 

The  previous  section  formulated  a set  of  invariants  to  define  structural 
objocts  and  structural  aggregation.  Based  on  these  invariants  we  define  a set  of  con- 
sistency rules  for  inserting,  deleting  and  updating  structural  objects.  The  important 
rules  for  manipulating  structural  objects  are  summarized  below: 

(1)  A complex  object  has  those  external  features  (of  the  components)  that 
are  involved  in  (a)  the  assembly  relations  of  the  complex  object,  and  (b)  the  external 
features  of  the  complex  object.  Therefore,  a parent  complex  object  acquires  a subset 
of  the  external  features  of  its  components  as  its  own  external  features;  and  the 
remaining  external  features  of  the  components  are  used  in  the  assembly  relations 
definition  among  components  (by  invariant  4.2.4’). 

(2)  A complex  object  is  built  bottom-up  from  predefined  (primitive  or 
other  complex)  objects.  The  external  features  of  a complex  object  cannot  be 
updated  (except  as  stated  in  condition  (4)  below),  as  these  features  physically  belong 
to  its  components  (by  invariant  4.2.1b). 

(3)  Updates  propagate  between  complex  objects  only  when  their  external 
features  are  changed.  Update  propagation  is  controlled  by  the  assembly  relations  of 
the  parent  object  (by  the  definition  of  assembly  relations  of  structural  objects). 

(4)  The  external  features  of  a complex  object,  A,  are  updated  only  when 
these  updates  do  not  change  the  external  features  of  any  object  declared  as  a com- 
ponent, Cj  e Cs,  of  A.  Therefore,  the  external  features  of  a complex  object.  A,  can 
be  changed  if  these  changes  are  the  result  of  either  (a)  updating  the  assembly  rela- 
tions, Rs,  of  A,  or  (b)  restricting  the  domain  of  one  or  more  characteristics  (of  the 
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external  features),  e.g„  using  only  a subset  of  the  length  of  the  spindle  in  the  flow 
control  valve.  For  all  other  cases,  only  the  external  features  of  the  primitive  objects 
can  be  changed  (by  invariants  4.2.1b  and  4.2.4'). 

(5)  By  definition,  any  change  to  the  internal  features  of  a complex  object  is 
not  visible  to  Us  parent  complex  object.  However,  changes  to  the  internal  features 
can  trigger  changes  to  the  external  features  of  the  same  object.  For  example, 
changes  to  an  object's  assembly  relations  may  trigger  updates  to  its  external  features. 
Any  update  to  the  external  features  are  subject  to  conditions  2 and  4 above  (by 
definition  of  structural  objects  and  invariant  4.2.1b). 

(6)  Changes  to  the  external  features  of  an  object  (complex  or  primitive),  A. 
trigger  updates  to  the  complex  object  that  contain  A as  a component  (by  invariant 
4.2.4'). 

(7)  The  relationship  between  the  components  of  a complex  object  can  be 
updated  by  altering  its  (complex  object's)  assembly  relationship,  Rs.  These  updates 
include  the  addition  or  deletion  of  a component.  Relationships  among  components 
can  be  redefined  as  long  as  these  updates  do  not  change  the  external  features  of  the 
components  from  condition  4 above  (by  invariant  4.2.4’). 

(8)  The  relationship  between  a complex  object  and  its  components  should 
be  consistently  defined  during  the  lifetime  of  the  object,  according  to  invariants  la. 
Ib,  and  2,  Components  participate  in  the  construction  of  a complex  object,  whereas 
a complex  object  identifies  its  components.  Deleting  a complex  object  will  cause,  by 
default,  all  the  physical  relationships  among  its  components  to  be  deleted.  This 
results  in  the  deletion  of  the  PART-OF  relation  from  the  complex  object  to  its  com- 
ponents and  assembly  relations  among  the  components.  A cascaded  delete  of  a com- 
plex object  will  delete  the  object  and  all  its  components  recursively,  with  only  the 
library  (or  primitive)  components  being  retained.  A complex  object  is  undefined 
unless  its  components  are  defined  (or  are  expected  to  be  defined  later). 


(9)  The  state  variable  values  are  updated  only  by  the  functional  objects 
which  simulate  the  behavior  of  the  structural  object  (by  the  definition  of  structural 
objects,  functional  objects,  and  interaction  objects).  Consistency  rules  for  inserting, 
deleting  and  updating  structural  objects  are  determined  from  the  above  invariants. 
The  important  characteristics  of  structural  objects  are  summarized  below. 

-1.3  Abstraction  of  Functional  Objects 

4.3.1  Introduction 

The  previous  section  described  the  modeling  of  the  functional  aspects  of  a 
domain.  This  section  describes  functional  object  abstraction  based  on  external 
features,  state  equivalences,  and  behavioral  equivalences. 

Structural  abstractions  are  widely  used  in  database  modeling  (SMI77, 
SCH80,  HAM81,  DAY84,  SU88J  to  represent  large  quantities  of  information  in  a uni- 
form and  concise  manner.  A second  category  of  abstraction,  called  process  abstrac- 
tion. is  useful  for  representing  behavioral  information  of  a domain  and  in  simulating 
systems  |FIS88|.  Research  in  programming  languages  have  developed  data  type 
abstractions  based  on  the  operational  view  of  the  data  [LIS75,  GUT77|.  Recently, 
database  research  has  employed  these  results  to  model  operations  on  data  (STO83, 
ONG84,  COP84,  AND87,  DAY87b,  ST087b,  SU89]. 

A formal  definition  of  functional  aggregation  is  given  below.  If  a functional 
object.  F,  is  the  aggregation  of  a set  of  objects,  Fi,  then  (a)  the  external  features  of 
Fi  are  abstracted  to  the  external  features  of  F;  (b)  state  equivalence  is  established 
between  F and  the  objects  in  Fi;  and  (c)  behavioral  equivalence  is  established 
between  F and  the  objects  in  Fi.  Generalization  of  functional  objects  is  similar; 
equivalence  is  established  between  the  generalized  object  F and  each  subfunction  in 
the  set  FI. 


‘1.3.2  Abstraction  of  External  Features 

Abstraction  of  the  external  features  of  the  components  of  Fi  is  defined  as 


where  HEAD(Fi)  are  the  input  variables  of  those  elements  of  Fi  that  receive  inputs 
from  the  external  world  (this  does  not  include  the  inputs  from  elements  of  Fi); 
TAIL(Fi)  are  the  output  variables  of  those  elements  of  Fi  that  send  outputs  to  the 
external  world  (this  does  not  include  the  outputs  to  elements  of  Fi).  The  above 
invariants  abstract  (i.e.,  by  taking  a subset)  the  external  features  or  the  subfunctional 
objects  to  the  external  features  of  the  parent  object,  F,  i.e.. 


4.3.3  State  Equivalence 

A morphism  between  the  state  variables  of  F and  their  components  should 
be  established  for  functional  abstraction.  Let  function  a map  the  states  of  objects  in 
Fi  to  the  states  in  F;  then  the  relationship  between  the  state-output  function,  /'/ ft , 
of  Ft  and  state  transfer  function.  P/sF,  of  F is  described  by  a commutative  diagram. 
Figure  4.2a,  (the  symbol  • denotes  composition  of  functions)  such  that 

PfsF  • a = a • P/Fi  (invariant_!.3.3) 
Invariant  4.3.3  states  that,  given  an  initial  system  (i.e.,  the  functional  objects  in  Fi 
have  an  associated  set  of  structural  objects  in  their  initial  states),  the  next  state  of  F 
is  determined  either  by  (a)  mapping  the  initial  state  of  Fi  to  F by  a and  then  apply- 
ing the  state  transfer  function,  P/sF,  or  (b)  applying  the  state-output  functions,  P/Fi, 
to  get  the  new  states  of  Fi  and  then  mapping  these  new  states  to  F by  a. 


HEAD(Fi)  C VlMIiFi) 
TAJLlFi)Qu  OUTf(Fi) 


(invariant_4.3.1a) 

(invariant-4.3.1b) 


INf  (F)=HEAD(Fi) 
OUTf  [F  )=TAIL  (Fi) 


(invariant_4.3.2a) 

(invariant_4.3.2b) 


-1.2b 


Behavior  equivalence  of  functional  objects;  in  and  out  arc  the 
and  the  output  variables,  respectively,  of  the  abstract  functional 
the  component  functional  objects  in  Fi. 


input  variables 
object,  F,  and 


Figure  q.2  Functional  abstraction 


A morphism  between  the  input-output  variables  of  F and  its  components 
should  be  established  for  functional  abstraction.  Let  function  8 map  the  input  values 
of  objects  in  Fi  to  the  input  values  of  F,  and  let  7 map  the  output  values  of  the 
objects  in  Fi  to  the  output  values  of  F.  Then  the  relationship  between  the 
state-output  functions.  P/p,  of  Ft  and  PfF  of  F,  is  described  by  a commutative 
diagram,  Figure  •1.2b,  such  that 

P/f  •P  — 'fPfpi  (invariant_‘l.3.'l) 

Invariant  4.3.4  states  that,  given  an  initial  system  and  a set  of  input  values 
to  Ft,  the  output  values  of  F are  determined  either  by  (a)  mapping  these  inputs  to  F 
by  8 and  then  applying  the  state-output  function,  PfF;  or  (b)  applying  the 
State-output  functions,  PfFi,  to  get  the  new  outputs  of  Fi  and  then  mapping  these 
new  outputs  to  F by  7. 

Notice  that,  from  invariants  4.3.2a  and  4.3.2b,  the  8 and  7 mappings 
correspond  to  the  HEAD  and  TAIL  functions,  respectively.  Therefore,  given  a set  of 
functional  objects,  Fi,  and  an  abstract  functional  object,  F,  there  exists  a three  sets 
of  functions,  a,  8,  and  7 that  satisfy  invariants  4.3.3  and  4.3.4. 

4.3.5  Example  of  Functional  Abstraction 

To  demonstrate  the  above  concepts  by  example,  we  will  show  the 
equivalence  between  the  functional  objects  of  the  top  two  levels  of  the  functional 
hierarchy  of  a How  control  valve  (see  Figure  2.3).  The  abstract  function  'Transmit 


o_;f^s *l., 

Cf:  Fl.F2.F3;  /•component*/ 

DEFINE  FUNCTIONAL  OBJECT:  FI 
EXTERNAL  FEATURES 

awsiKi!sau 

I„:s 


OUTf^Stion" 


L OBJECT:  F2 

3®a-_ 


TONAL  OBJECT:  F2. 


Ka™!™ 

INPUT:  CJV C_POSi: 

Z.^ssfe, 


Rf:  /-connection  relations*/ 
END  FUNCTIONAL  OBJECT:  F3. 
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generate  the  new  value  of  status  for  the  valve.  Status  is  the  state  variable  defined  in 
the  structural  object,  flow  control  valve.  The  output  function  uses  the  current  status 
lo  compute  the  output  flow.  Fo.  The  components  of  F are  FI,  F2,  and  F3  and  are 
defined  in  the  component  section.  Cf.  The  connection  relations,  Rf.  show  how  the 
output  values  of  one  component  object  are  transmitted  lo  the  inputs  of  the  other 
component  objects.  Here,  for  example,  in  Rl  the  SEQuence  (connection)  relation 
transfere  the  output  flow  of  object  FI,  Fl.P_Fo,  to  the  input  flow  of  object  F3, 
F3.C_Fi. 

Similarly,  the  definition  of  the  functional  objects  FI,  F2,  and  F3  are  given 
above.  The  object  FI  updates  the  state  variable  called  input  flow  rate.  SF1;  F2 
updates  the  state  variable  called  (spindle)  position,  SP;  and  F3  updates  the  state  vari- 
able called  output  flow  rate,  SF2. 

The  rest  of  this  section  uses  the  above  functional  object  definitions  to  for- 
mally verify  the  abstraction  conditions  stated  in  invariants  4.3.1,  4.3.2,  4.3.3,  and 
4.3.4.  Verification  consists  of  three  steps;  (a)  to  show  the  abstraction  of  external 
features,  (b)  to  show  behavioral  equivalence,  and  (c)  to  show  state  equivalence.  Fig- 
ure 4.3  gives  a graphical  view  of  the  functional  objects  F,  FI,  F2,  and  F3  above,  and 
is  useful  as  a pictorial  aid  to  understand  the  following  discussion  on  functional 
abstraction. 

(a)  The  following  steps  show  the  abstraction  of  external  features  of  functional 
objects  FI,  F2,  and  F3  to  the  abstract  functional  object  F. 

(i)  From  FI,  F2,  and  F3,  the  input  features  are 
Umf(Fi) 

- Up  {{P_Fi},  {V_Ti},  {C_F1},  {C_POSi}} 

- (P_Fi,  V_Ti,  C-Fi,  C-POSi} 


Figure  1.3 
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(11)  From  FI,  F2,  and  F3,  the  output  features ; 
U OUT! (Ft) 


- UF  {{P-Fo},  {V_POSo},  (C_Fo}> 

= {P_Fo.  V_POSo,  C_Fo} 

(iii)  Applying  the  HEAD  and  TAIL  functions  to  the  input  features  and  the  out- 
put features,  respectively,  we  get 

HEAD(Fi)-P-Fi,V-Ti  (1) 

TAIL(Fi)=C-Fo  (2) 

(Iv)  The  input  and  output  features  of  the  abstract  functional  object.  F,  is  given 

IN(F)-Fi,Ti  (3) 

OUT(F)-Fo  {4) 

(v)  On  examining  (1),  (2),  (3),  and  (4),  we  find  that  (I)  = (3)  and  (2)  - (4). 
Therefore, 

HEAD(Fi)  = IN(F)  and  TAIL(Fi)  = OUT(F) 
ignoring  differences  in  variable  labels.  This  result  is  directly  verified  from  Figure 


(b)  The  following  steps  show  the  behavioral  equivalence  between  the  functional 
objects  FI,  F2,  and  F3  and  the  abstract  functional  object  F. 

(i)  Define  the  function  0 which  maps  the  inputs  or  FI  and  F2  to  the  inputs  of  F, 
and  the  function  -y  which  maps  the  output  or  F3  to  the  output  of  F,  as  follows: 

0*“{0l,  02} 

where  01  maps  the  inflow,  P_Fi,  of  functional  object  FI  to  the  inflow  of  the 
abstract  functional  object  F,  i.e„  P_Fi  = Fi.  Similarly,  01  maps  the  torque, 


V_T1  of  functional  object  F2  to  the  torque  of  the  abstract  functional  object  F, 
i.e.,V_Ti-Ti. 

The  mapping  1 relates  the  outflow,  C_Fo,  of  the  functional  object  F3 
to  the  outflow  of  the  abstract  functional  object  F,  i.e.,  C_Fo  = Fo.  Refer  to 
Figure  4.3  for  these  mappings. 

(ii)  According  to  the  left-hand  side  of  invariant  4.3.4,  apply  0 to  the  input 
values  of  FI  (i.e.,  P_Fi  and  V_Ti)  to  get  the  inputs  for  the  state-output  function, 
f_transmit,  of  F,  and  then  apply  f_transmit  on  these  Inputs: 

f —transmit  • 0 

—*  f-transmit(/?l,  01) 

— » f-transmit(Fi,  Tt) 

— Fo 


(iii)  Apply  the  inputs  to  the  state-output  functions  of  FI  and  F2,  i.e.,  f-pass 
and  f—vary,  and  then  use  the  connection  relations  to  map  the  outputs  of  FI  and 
F2  to  the  input  of  F3.  We  then  get  the  state-output  function  of  F3  as 
f_control(C_Fi,  C_POSi).  Apply  1 to  the  output  of  f_control.  According  to  the 
right-hand  side  of  invariant  4.3.4, 

1 • f_control(C_Fi,  C-POSi) 


When  the  inputs  to  the  components,  FI,  F2,  and  F3,  are  mapped  to 
the  inputs  of  the  abstract  object,  F,  and  the  state-output  function  of  F is 
applied,  we  must  get  the  same  output  as  when  the  components  apply  their 
state-output  functions  and  then  map  the  output  to  the  output  of  the  abstract 
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object,  F.  When  the  above  commutative  relationship  holds  then  it  is  guaranteed 
that  F is  behavioraliy  equivalent  to  FI,  F2,  and  F3. 

(c)  The  following  steps  show  state  equivalence  between  Fl.  F2,  and  F3  and  the 
abstract  object  F. 

(1)  Define  a state  equivalence  function,  a.  from  the  state  variable,  position,  or 
the  subfunctional  object,  F2,  to  the  state  variable,  status,  of  the  abstract  func- 
tional object,  F. 

The  state  equivalence  function  (in  this  case)  is  a characteristic  function 
that  maps  the  state  space  of  position  (i.e.,  0 to  380  degrees)  to  the  state  space  of 
status  (i.e.,  ON,  OFF)  such  that  if  the  spindle’s  position  is  between  45  and  315 
degrees,  the  flow  control  valve's  status  is  ON;  otherwise  the  valve  is  OFF. 

In  the  above  example,  only  the  spindle  position,  SP,  in  F2  is  related  to 
the  status  in  F,  so  PfsF  = f_t  (from  the  definition  of  functional  object  F)  and 
Pf Fl  = P/sF  a “ f-v  (from  definition  of  functional  object  F2). 

(ii)  Let  the  initial  position  of  the  spindle  be  0 degrees,  and  let  the  input  torque, 
T,  to  the  valve  move  the  spindle  by  50  degrees.  Use  a to  map  the  initial  state  of 
F2  to  F;  this  gives  the  initial  state  of  F as  status  - OFF. 

(iii)  Applying  the  state  transfer  function  of  F,  f_t,  on  the  initial  state,  status  - 
OFF,  and  the  input  torque,  T,  gives  the  new  state  of  F as  status  = ON. 

(iv)  Applying  the  state  transfer  function  of  F2,  f_v,  on  its  initial  state,  position 
= 0,  and  the  input  torque.  T,  gives  the  new  state  of  F2  as  position  = 50. 

(v)  Mapping  the  new  state  of  F2  to  the  state  of  F by  a,  we  get  status  = ON. 

The  commutative  relation  described  in  steps  (i)  to  (v)  above  should  guaran- 
tee state  equivalence  between  functional  object  F and  its  subfunctional  objects  Fl, 


F2,  and  F3. 


The  above  discussion  defines  and  verifies  functional  abstraction  among  func- 
tional objects.  For  F_\GG  the  above  results  directly  apply;  for  F_GEN.  external 
feature  abstraction,  state  equivalences,  and  behavioral  equivalences  have  to  be  shown 
between  F and  each  element  in  Fi. 

The  connection  relations,  by  definition,  transfer  data  values  among  func- 
tional objects  and  do  not  update  system  state  or  modify  data  values.  Connection 
relations  are  integrated  into  the  above  framework  by  expressing  them  in  terms  of 
mappings  between  the  output  variables  of  one  or  more  functional  objects  to  the  input 
variables  of  one  or  more  functional  objects.  For  SEQUENCE,  BROADCAST, 
MERGE,  and  REPEATING,  these  mappings  are  static  and  are  directly  obtained 
from  their  definitions.  For  example,  SEQ(Fl.P-Fo,  F3.C_Fi)  maps  the  output 
feature,  P-Fo,  of  object  FI  to  the  input  feature,  C-Fi,  of  the  object  F3.  The  CON- 
DITIONAL and  MEET  connection  relations  are  determined  by  the  data  values 
obtained  during  run  time. 

This  concludes  the  discussion  on  functional  abstraction.  Functional  abstrac- 
tion is  more  complex  than  structural  abstraction,  (section  4.2),  because  for  functional 
abstraction  the  state  equivalence  and  behavior  equivalence  have  to  be  established 
between  the  abstract  object  and  its  components.  The  next  chapter  will  show  how 
constraints  are  specified  and  satisfied  in  the  SF  paradigm. 


CONSTRAINT  SPECIFICATION  AND  SATISFACTION 


simulation,  and  monitoring  en' 


snstraints  in  design  |BR086, 


quantities  of  data  and  knowledge  [BOR8I,  STE81]  over  a long  period  of  time. 


system  states,  checking  these  events  for  consistency,  recalling  past  events  when 


nstraint  satisfaction  system  needs  them,  and  taking  actions  based  on  the  nature 
event.  Aba,  the  constraint  system  should  accommodate  transactions  where 
item  is  inconsistent  for  long  times  [DIT86]  by  temporarily  disabling  portions  of 


Constraints  model  the  integrity  of  systems  by  enforcing  relationships  among 
ependent  variables.  For  example,  to  prevent  leakage  in  a flow  control  valve  the 
diameter  of  the  sealing  bush  should  be  equal  to  the  outer  diameter  of  the  spin- 
ny  change  to  the  outer  diameter  of  the  spindle  will  trigger  a constraint  to 
e this  relationship.  This  constraint  either  updates  the  inner  diameter  of  the 

I bush.  By  defining  constraints,  an  engineer  can  delegate  to  the  constraint 


Database  research  in  constraints  can  be  divided  into  two  broad  categories: 
static  constraints  and  dynamic  constraints.  Static  constraints  are  either  (a)  structural 
constraints  that  implicitly  enforce  the  integrity  of  the  database  model,  e.g.,  key  con- 
straint. referential  integrity  constraint,  and  the  entity  integrity  constraint  of  the  rela- 
tional model  [ELM89];  (b)  cardinality  constraints  in  the  entity-relationship  model 
[CHE76];  and  (c)  application  constraints  that  define  the  legal  states  of  the  system  (at 
all  times)  (MOR81],  e.g.,  age  of  employee  is  greater  than  18.  Dynamic  constraints 
are  defined  over  a sequence  of  states  and  use  temporal  dependencies  among  states  to 
define  and  enforce  these  constraints  (EHR8-I,  KUN8S,  UP87).  For  example,  an 
employee's  salary  cannot  decrease.  Dynamic  constraints  are  common  in  engineering 
design  and  manufacturing  applications.  In  manufacturing  there  is  a definite  sequence 
of  steps,  and  each  step  is  a process  aimed  at  meeting  the  design  specifications.  For 
example,  to  manufacture  a bolt,  first  the  raw  material  has  to  be  turned,  then  milled, 
and  finally  threaded.  In  each  stage,  the  state  of  the  bolt  is  governed  by  a set  of 

The  constraint  specification  and  satisfaction  system  can  be  naturally 
modeled  by  the  structure-function  paradigm  proposed  earlier.  Structural  objects 
model  the  features  of  a design.  These  features  include  the  state  variables,  Ps,  exter- 
nal features,  Es,  component  definitions,  Cs,  and  assembly  relationships  among  com- 
ponents, Rs.  Each  functional  object,  on  the  other  hand,  represents  a constraint 
which  tests  and  enforces  consistency  among  the  features  of  the  structural  objects. 
The  interaction  object  maps  events  on  a feature  of  the  structural  object  to  a con- 
straint (functional  object),  or  maps  events  in  the  functional  object  to  features  of  a 
structural  object. 

This  chapter  first  describes  the  constructs  of  the  constraint  specification  and 
satisfaction  system;  then  a complete  description  of  constraint  propagation  is  given. 


straint  objects.  F,  to  structural  objects.  S;  and  M2  maps  state-output  functions,  Pf, 
to  structural  features.  Cv.  These  mappings  are  similar  to  those  between  the  struc- 
tural objects  and  the  functional  objects  explained  in  subsection  3.2.3.  Type  M3  maps 
the  events  defined  on  features.  Cv.  of  a structural  object  to  the  constraint  objects,  or 
maps  the  events  generated  by  a constraint  object  to  the  features  of  the  structural 

As  in  the  case  of  the  Ml  and  M2  mappings,  the  M3  mappings  are  declara- 
tive. and  modular,  and  are  treated  as  data.  There  are  two  types  of  M3  mappings-l:l 
correspondence  and  l:n  correspondence. 

In  the  1:1  correspondence,  one  event  defined  over  a structural  feature  maps 
to  one  constraint  object,  and  one  constraint  object  maps  to  one  event.  This  is  the 
straightforward  case  and  is  represented  as 

M3  - {m3  | m3  - <Sj.Cv.Vj,  Fi>} 

where  Sj.Cv.Vj  represents  the  event  Vj  defined  over  the  feature  Cv  (of  a structural 
object  Sj),  and  Fi  is  a constraint  object. 

Also,  one  event  defined  over  a variable  in  the  constraint  object  maps  to  a 
feature  in  the  structural  object: 

M3  - {m3  | m3  - <Sj.Cv,  Fi.Cv.Vj>} 

where  Sj.Cv  represents  the  feature  Cv  of  a structural  object  Sj,  and  Fi.Cv.Vj 
represents  the  event  Vj  defined  over  the  variable  Cv  of  the  constraint  object  Fi. 

In  the  l:n  correspondence,  one  event  defined  over  a structural  feature  maps 
to  many  constraint  objects.  When  the  structural  feature  value  is  changed,  all  these 
constraint  objects  are  invoked.  For  example,  the  spindle  is  physically  connected  to 
the  sealing  bush,  the  bearing  bush,  and  the  threaded  bearing  bush  in  the  flow  control 
valve  (see  section  2.3).  If  the  relationships  between  the  dimensions  of  the  spindle  and 
each  of  the  bushes  are  expressed  by  separate  constraints,  then  any  change  to  the 


outer  diameter  of  the  spindle  will  invoke  all  three  constraint  objects.  The  M3  map- 
ping is  denoted  as 

M3  = {m3  I m3  - <Sj.Cv.Vj,  AND(Fl,  F2 Fi)>} 

where  Sj.Cv.Vj  represents  the  event  Vj  defined  over  the  feature  Cv  (of  a structural 
object  Sj)  that  participates  in  all  the  FI,  F2, ....  Fi  constraint  objects. 

A^ertcr~  An  alerter  is  a watch-dog  or  monitoring  mechanism  defined  on  a 
structural  feature,  Cv.  Whenever  this  feature  is  cither  updated  or  exhibits  a 
prespecified  behavioral  pattern,  the  alerter  signals  an  event  to  the  constraint  object 
or  to  the  structural  object  through  the  M3  mappings.  Alerters  also  signal  when  a 
prespecified  time  is  reached,  or  some  time  has  lapsed  after  a certain  event.  As  will  be 
seen  later  in  section  5.7,  alerters  are  used  to  control  the  propagation  of  constraints  by 
asserting  whether  or  not  a structural  feature  (based  on  its  current  value  or  history  of 
its  past  values)  will  participate  in  a constraint. 

There  arc  two  types  of  alerters-memoryless  alerters  and  memory-based 
alerters.  Memoryless  alerters  are  defined  to  signal  on  either  the  insertion,  deletion,  or 
update  of  a structural  feature.  These  alerters  do  not  use  the  past  states  of  the 
feature  to  generate  a signal.  A memoryless  alerter  can  also  be  defined  to  signal  at  a 
prespecified  time,  say,  8:00  a.m.  Memory-based  alerters  are  defined  to  signal  on  pre- 
vious values  or  the  trend  of  past  values  of  the  structural  feature  (e.g.,  if  the  pressure 
creeses  a threshold  value  more  than  ten  times  within  a 24  hour  period,  the  operator 
should  be  alerted).  Memory-based  alerters  are  also  used  to  resolve  (a)  cycles  in  a 
constraint  propagation  path  by  monitoring  the  trend  of  the  feature;  and  (b)  conflicts 
when  two  or  more  values  are  generated  for  a structural  feature  during  constraint 
propagation.  For  example,  if  the  temperature  of  an  engine  is  computed  from  two 
sources,  the  alerter  can  be  programmed  to  pick  the  average,  maximum,  minimum,  or 
latest  value,  or  to  alert  the  user  of  an  inconsistent  temperature  reading. 


Events~  Events  are  recognisable  happenings  in  the  database,  such  as  reach- 
ing a state,  starting  an  action,  or  terminating  an  action.  Events  are  essential  in 
designing  databases  that  have  to  monitor  their  own  states  and  take  actions  based  on 
(a)  these  states  and  (b)  the  stimulus  from  the  outside  world.  The  main  characteris- 
tics of  an  event  arc  that  it  should  be  detectable  and  well-defined  to  be  captured  by 
data-modeling  constructs.  In  this  constraint  system,  events  are  defined  either  by 
alerters  (as  in  the  case  of  D_evcnts  and  V_events,  described  below)  or  by  triggering 
constructs  (as  in  the  case  of  F-events,  described  below). 

They  are  the  data  event,  D-event;  the  function  event,  F_event;  and  the  virtual 


5.3  Definition  of  Events 

Events  are  essential  in  detecting  the  state  of  the  system,  initiating  and  ter- 
minating  actions,  and  reviving  past  event  signals  that  were  ignored  due  to  the  exist- 
ing conditions.  This  section  describes  the  different  types  of  events  in  detail. 

5.3.1  D_event 

The  role  of  this  event  is  to  signal  when  the  system  reaches  a predefined 
state,  or  when  the  input  data  generated  by  an  industrial  monitoring  process  reaches  a 
predefined  critical  value.  These  events  are  specified  by  alerter  constructs  that  trigger 
on  data  vaiue(s)  and/or  the  temporal  aspect  of  the  data  value.  Examples  of 
D_events  are  (a)  the  temperature  crossing  a threshold;  (b)  the  temperature  increas- 
ing; (c)  the  rate  of  arrival  of  components  on  a conveyor  belt  being  below  rated  value; 
or  (d)  the  time  being  8:00  a.m.  For  the  sake  of  modularity  and  expandability,  a 
D_event  is  defined  on  only  one  feature  of  a structural  object  and  does  not  directly 


initiate  any  updates  to  the  database.  As  all  features  are  stored  in  the  structural 
object,  only  structural  objects  issue  D-events. 


A D-event  is  defined  as 

feature-name:  domain, 

EVENT:  Vi 

ALERT:  Pointer  to  M3  mapping; 
ON:  &_value 

WHERE  statement; 

WHEN  statement; 

DELAY:  # execution  cycles; 


Feature-name  is  a structural  feature  of  the  structural  object  on  which  the  D_event  is 
defined.  The  key  word  EVENT  specifies  the  name  of  the  event,  Vi.  The  key  word 
ALERT  defines  the  pointer  to  the  M3  mapping.  The  pointer  to  the  M3  mapping  is 
the  concatenation  of  the  interaction  object  name  (or  id)  and  the  name  (or  id)  of  the 
M3  mapping.  The  key  word  ON  defines  the  triggering  condition  on  which  the  alerter 
generates  a D-event.  This  condition  defines  an  envelope  of  states  and/or  a sequence 
of  states  of  the  feature  on  which  the  D-cvent  will  signal  the  constraint  object.  The 
ON  condition  is  composed  of  a signal  value,  s-value,  the  WHERE  statement,  and  the 
WHEN  statement.  The  signal  value,  s_value,  consists  of  the  event  id  and  the  current 
state  vaiue  (or  set  of  state  values)  which  is  sent  to  the  constraint  object  when  the 
alerter  triggers.  The  WHERE  statement  contains  the  monitoring  conditions  on  the 
value  of  the  feature,  whereas  the  WHEN  statement  contains  the  monitoring  condi- 
tions on  the  temporal  trend  of  the  feature.  Each  feature  can  have  many  alerters,  i.e., 
distinct  monitoring  conditions  that  point  to  different  sets  of  constraint  objects. 
DELAY  specifies  the  number  of  execution  cycles  that  the  alerter  can  remain  idle 
before  it  can  issue  a new  D-event.  This  delay  synchronizes  the  rate  at  which  events 
are  fed  to  the  constraint  system  with  the  response  of  the  system.  A zero  delay 
means  that  the  alerter  signals  D-events  as  they  are  detected;  infinite  delay  means 
that  the  alerter  signals  only  one  D-event  and  then  has  to  be  manually  reset  before 
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signaling  any  other  D-event.  The  default  delay  for  a D-cvent  is  one  execution  cycle. 
The  period  of  the  execution  cycle  is  predefined  by  the  designer  and  corresponds  to 
the  average  time  the  system  needs  to  respond  to  a O-event.  More  precisely,  it  is  the 
time  between  the  firing  of  a D-event  and  the  firing  of  the  F-end  event  (to  terminate 
the  action  initiated  by  the  D-event). 

The  next  three  subsections  define  the  different  components  of  the  ON  con- 
dition in  greater  depth.  As  stated  earlier,  the  ON  condition  consists  of  the  s_value, 
WHERE  statement,  and  the  WHEN  statement. 

5.3.X.1  S-value 


The  s_value  is  the  signal  that  the  alerter  sends  to  the  constraint  object.  If 
no  value  is  specified  and  the  alerter  fires  successfully,  then  TRUE  is  returned;  other- 
wise, the  alerter  returns  (a)  the  current  value  of  the  feature;  (b)  a past  value  selected 
on  basis  of  a selection  criteria,  such  as  maximum,  minimum,  etc.;  (c)  a set  of  values; 
(d)  an  aggregation  of  previous  values;  or  (e)  a predefined  value. 

The  format  of  the  s-value  is  a concatenation  of  the  event  id  and  a data 
value  (or  a set  of  data  values)  of  the  feature.  The  event  id  consists  of  the  structural 
object  name  and  the  feature  name  on  which  the  D-event  is  defined. 

The  different  types  of  data  values  returned  by  the  signal  for  a feature  x are 


(*•  ‘) 

SET(x,  (tl  ..  t2]) 
MAX(x,  [tl ..  t2|) 
MIN(x,  (tl ..  t2j) 
AVE(x,  [tl ..  t2[) 
COUNT(x,  [tl  ..  t2|) 


single  current  value 

single  value  at  time  t 

set  of  values  in  interval  [tl ..  t2) 

maximum  value  in  interval  [tl  ..  t2| 

minimum  value  in  interval  [tl  ..  t2) 

average  value  in  interval  (tl ..  t2| 

total  number  of  values  in  interval  [tl  ..  t2| 


slope  of  x defined 


FIX  c 

SLOPE(x,  |tl,  t2|) 
DIFF(x,  (t,  H|) 
RESULT 


slope  of  x defined  between  |tl,  t2j 

tuples  that  satisfy  the  WHERE  and  WHEN  sti 


The  WHERE  statement  consists  of  monitoring  conditions  defined  on  the 
data  value  or  the  feature,  x.  These  conditions  are  combined  together  by  the  boolean 
operators  OR,  AND,  and  NOT.  A monitoring  condition  is  satisfied  if  there  exists  a 
database  extension  that  satisfies  all  the  conditions  in  the  WHERE  statement.  The 
general  form  of  the  monitoring  condition  is  shown  below: 


WHERE  <statement> 

statement  :=  <statemcnt>  <bool>  <cond>  I 

<cond> 

cond ^ NOT  <condltion>  | 

condition  ■•=  (x,  t)  <comp>  <expression>  | 

x <comp>  <expres9ion>  | 

<comp_vaiue>  <comp>  <constant>  I 
insert(x,  t)  |delete(x,  t)  |update(x,  t) 

expression  t-i)  | a / (x,  M)  1 1 a + (x,  W)  1 - (x,  W 

AVE(x,'tV| 

SUM  x,  t) 

PRODjx,  t)  | 


comp-value  :=  SLOPEfx,  t)  | COUNT  "("  <condition>  T 

bool  :=  AND  |OR  | 

comp  :—  < | > |<|>|-|!- 

constant  :=  int  | real 


All 


Here,  (x,  t ) is  the  time  stamped  variable 
WHEN  statement  is  on  the  x variable,  the  value  (or  r 
by  the  WHEN  statement  described  below. 

S.3.1.3  WHEN  statement. 


The  WHEN  statement  consists  of  monitoring  conditions  defined  on  the 
unporal  aspect,  t,  of  the  feature.  These  temporal  conditions  arc  combined  by  the 
»lean  operators  OR,  AND,  and  NOT.  The  monitoring  condition  is  satisfied  if 
tere  exists  a temporal  database  extension  (or  a time  window)  which  satisfies  the 
mditions  in  the  WHEN  statement.  The  general  form  of  the  monitoring  condition  is 
own  below: 


tatement>  <bool>  <cond>  | 
NOT  <condition>  | 


BEFORE(x.  a)  <t_comp>  <constant>  I 
AFTERfx.  a)  <t_comp>  <constant>  I 
((x,  t)  - NOW)  <t_comp>  <constant> 
bool  :=  AND  |OR  | 
t-comp  < |>  |<|>  li- 


lt |yeai 


nonlh:da 


ALL(x,  t)  states  that  tuples  qualify  for  all  values  of  t;  BEGIN(x,  a)  a 
END(x,  a)  fixes  the  absolute  start  and  end  tuple  time  stamps  at  time  “ 
BEFOREfx,  a)  and  AFTER(x,  a)  is  the  relative  time  starting  from  time  stamp  ' 
and  proceeding  for  a length  of  time  specified  by  the  "constant."  The  express 
t)  - NOW)  denotes  the  time  starting  from  the  current  time  and  extending  I 


son  ((x, 


aggregation  condition 


max-p,  more  than  ten  times.  The  construct  (p,  t)  is  the  time-stamped  variable  of 
pressure,  p.  The  boolean  conjunctions  AND,  and  OR.  relate  two  or  more  conditions 
in  the  WHERE  statement. 

An  example  of  a memory-based  alerter  that  triggers  if  the  pressure  value 
crosses  max-pressure,  inax-p,  more  than  10  times  within  5 hours  is  given  by 


pressure,  p:  real 
EVENT:' 
{ 


} 


ALERT:  lnteraclion_objectAi3_namc: 
ON:  (p,  t) 


WHEN  ((p.  t)  - NOW)  < 5h: 


WHEN  is  a temporal  statement  defined  on  the  time-stamped  value  of  the 
feature  [NAVBDj.  This  temporal  statement  is  satisfied  when  the  database  contains  a 
set  of  tuples  that  satisfies  all  the  temporal  conditions  of  the  statement;  in  this  case, 
their  time  stamps  should  be  within  5 hours  of  the  current  time.  The  alerter  signals  a 
D_event  only  when  the  set  of  (p,  t)  values  that  satisfies  the  maximum  presmre  con- 
straint in  the  WHERE  statement  also  satisfies  the  temporal  constraint,  l.e„  pressure 
exceeded  maximum  within  the  LAST  5 hours.  The  key  word  NOW  denotes  the 


of  the  feature  with  the  conditions  on  the  value  of  the  feature.  In  such  cases,  the  tem- 
poral information  is  expressed  within  the  WHERE  statement.  For  example,  an 
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AUKTiInteractionjbjcctAC-j.arae: 


e,(p,t).  In  general, 
rent  value,  (p,t),  it  is  possible  to 


ct  of  the  feature  in  the  YY 


ts  on  one  feature  of  a 


rea,™.^. 
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interaction  object  name  (or  id)  and  the  name  (or  id)  of  the  M3  mapping.  The  M3 
mappings  contain  coupling  information  that  enables  the  constraint  object  to  read 
data  values  (or  the  feature)  from  the  structural  object.  FIND  specifies  the  data 
needed  by  the  V_event  and  is  similar  in  construction  to  the  ON  construct  of  the 

The  role  of  this  event  is  to  determine  when  to  initiate  or  terminate  the 
testing  of  constraints  and  the  execution  of  actions  based  on  the  D_events  generated 
by  the  structural  objects.  A D-event  can  initiate  actions  in  the  database  only  if  it 
can  activate  a constraint  object  by  triggering  an  F_event.  An  F_event  is  defined  by 
either  the  activation  rule  or  the  deactivation  rule.  The  F_event  that  is  deHned  by 
the  activation  rule  is  called  the  F-start  event,  and  the  F_evcnt  that  is  defined  by  the 
deactivation  rule  is  called  the  F_end  event. 

An  F_start  event  specifies  (a)  the  D-events  needed  to  activate  a constraint 
object;  or  (b)  user  inputs  needed  to  activate  a constraint  object.  For  example,  the 
D-events  on  position  and  velocity  vector  are  to  be  present  before  an  F-start  event 
can  be  issued  to  start  a trajectory  correction  constraint  procedure  for  a spacecraft. 
An  F_end  event  specifies  (a)  the  D-events  needed  to  deactivate  the  constraint  object; 
or  (b)  the  outputs  from  the  system  (either  from  the  functional  objects  or  the  con- 
straint objects)  that  terminate  an  action.  Examples  of  F-end  events  include  a clock 
running  out,  a successful  process  for  establishing  contact  between  two  remote  hosts, 
or  receiving  sensor  input  which  stops  the  movement  of  a robot's  arm. 
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F-start  events  can  be  temporarily  disabled  by  the  designer,  in  which 
the  constraint  satisfaction  has  to  be  done  manually. 

An  F-start  event  is  defined  as 


PRIORITY:  |nl..o2|; 

IF:  Dl_events  or  user  specified  control; 
ACTIVATE:  constraint  object: 
DISABLE:  yes/no; 


The  key  word  EVENT  specifies  the  name  of  the  activation  rule;  by  default,  the  event 
name  defaults  to  the  name  of  the  constraint  object  and  can  be  omitted.  The  key 
word  IF  is  the  activation  condition  to  trigger  the  F-start  event.  It  consists  either  of 


a combination  of  D-events  or  a set  of  user  inputs  related  by  conjunctions  and  dis- 
junctions. The  ACTIVATE  key  word  specifies  the  constraint  object  that  will  be 
activated  when  the  F-start  event  is  triggered.  DISABLE  is  a manual  override  by  the 
user  to  temporarily  disable  the  constraint.  The  F_end  event  is  similarly  defined, 
except  that  the  ACTIVATE  key  word  is  substituted  with  DEACTIVATE. 

F-events  are  scheduled  to  trigger  based  on  their  priority,  which  is  normally 
dictated  by  the  urgency  of  the  needed  action.  Priority  is  denoted  by  a number 
within  the  range  |nl..n2|.  The  highest  priority,  i.e.,  n2,  means  that  the  F_event 
triggers  with  no  delay.  When  all  the  D_events  (or  user  inputs)  are  present,  a token 
(i.e.,  event  id)  for  the  F-start  event  is  placed  in  the  event  ready  queue.  Based  on  the 
priority  and  the  position  in  the  queue,  the  F-start  event  is  triggered,  creating  an 
activation  instance  of  the  constraint  object  (the  activation  mechanism  is  similar  to 
one  described  in  Chapter  3 for  a functional  object). 
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5.4  Definition  of  Constraint  Object* 


U>  the  functional  object  and  is 


DEFINE  CONSTRAINT  OBJECT:  name 
EXTERNAL  FEATURES 

INTERNAL  FEATURES 

STATE-OUTPUT  FUNCTION 
TEST: 

ACTION: 

COMPONENTS  /*  sub  constraints 
CONNECTION  RELATIONS  /*  r 
END  CONSTRAINT  OBJECT:  name 


and  enforces  dependencies  among  features  of  the  structural  object.  The  key  word 
EXTERNAL  FEATURES  defines  the  structural  features  checked  by  the  constraint 
objects.  The  key  word  STATE-OUTPUT  FUNCTION  consists  of  two  parts:  the 
TEST  which  defines  and  checks  the  constraint,  and  the  ACTION  which  recomputes 
the  values  for  the  features.  The  key  word  COMPONENTS  defines  the  subcon- 
straints that  satisfy  the  constraint  at  a greater  level  of  detail.  The  key  word  CON- 
NECTION RELATIONS  relates  the  subconstraints  to  one  another.  The  components 
and  connection  relations  (a)  organize  and  group  a set  of  constraint  objects  (e.g„  con- 


constraints  used  during  simulation  are  not  used  in  the  manufacturing  phase),  and  (b) 
delegate  a high-level  constraint  to  more  primitive  constraints. 


5.-I.1  External  Featn 


External  features  define  the  structural  features  that  are  constrained  in  the 


.1.2  Internal  Features 


utput  func- 
tion, which  consists  of  a TEST  and  an  ACTION  part,  the  component  constraint 
declarations,  and  the  connection  relations.  The  ACTIONS  arc  procedural  or  declara- 
tive information  which  update  the  structural  object  to  keep  it  in 

An  ACTION  depends  on  the  results  of  the  TEST  part  of  the  output  fun 
The  different  types  of  TEST  conditions  are  as  follows: 

(a)  Membership  constraint  specifies  that  a feature  belongs  to  a certain  class  01 


a e {Al,  A2,  A3} 

(b)  Bounded  constraint  limits  the  possible  values  of  a feature,  e.g.,  a feature  can  have 
any  value  between  Al  and  A2. 

a e [Al,  A2) 

(c)  Equations!  constraint  relates  two  or  more  features  by  simple  arithmetic  or 

boolean  operators.  The  arithmetic  operators  are  +,  *,  /,  he.,  add.  subtract,  multi- 

ply, and  divide.  The  boolean  operators  are  AND,  OR,  and  NOT.  Some  examples  of 
equational  constraints  are 

al  + a2  < a3 
al  AND  a2 

(d)  Trend  or  gradual  degradation  constraint  allows  for  gradual  degradation  of  a 
feature  and  takes  actions  depending  on  the  severity  of  the  degradation  (e.g.,  when 
the  temperature  climbs  above  a threshold,  the  coolant  system  is  checked;  if  the  tem- 
perature climbs  further,  the  operator  is  informed;  if  the  climb  is  not  checked,  the 
plant  is  shut  down). 


1,  A2,  A3> 


a <A4,  A5,  A6> 

where  Al,  A2,  A3,  A4,  A5,  and  A6  are  the  possible  failure  modes  for  variable  a. 
This  is  interpreted  as:  the  system  operates  normally  between  A3  and  A4;  between  Al 
and  A3  and  between  Al  and  A6  the  system  is  operating  under  different  levels  of 
degradation:  below  Al  and  above  A8  the  system  is  considered  nonoperational. 

(e)  Temporal  constraints  order  the  sequence  of  D-events.  The  different  temporal 
constraints  on  I) -events  a and  b are  given  below: 

a BEFORE  b (a  happens  before  b) 
a AFTER  b (a  happens  after  b) 
a DURING  b (a  and  b overlap) 
a END  b (a  and  b terminate  at  the  same  time) 
a START  b (a  and  b start  at  the  same  time) 

These  temporal  constraints  are  defined  on  two  D-events.  Constraints  on  multiple 
events  are  defined  by  combining  these  constraints  by  boolean  constructs. 

(f)  Failure  pattern  detection  constraint  detects  a failure  by  checking  for  patterns  in 
the  data  across  the  system  over  a specific  time  interval.  For  example,  the  frequency 
of  rejection  of  parts  on  an  assembly  line  sharply  increased  after  the  conveyor  belt 
was  increased  by  20  percent.  The  specification  of  this  test  condition  is  similar  to  the 
WHERE  and  WHEN  statements  of  the  alerters  (defined  in  subsection  5.3.1);  here 
however,  the  test  is  conducted  on  more  than  one  feature  (e.g.,  the  failure  rate  and 
belt  speed). 

5.4.3  Components 

Components  is  a list  of  subconstraints  that  together  satisfy  the  parent  con- 
straint. When  the  parent  constraint  detects  that  a condition  is  violated,  it  delegates 
the  constraint  checking  (and  action)  to  other  constraint  objects  to  keep  the  system 


consistent.  This  is  done  by  invoking  the  subconstraints  to  check  different  aspects  of 
the  system  and  take  corrective  action.  The  parent  constraint  is  satisGed  only  when 
all  the  subconstraints  are  satisGed.  For  example,  if  the  external  casing  dimensions  of 
a d.c.  motor  is  decreased  by  5 percent,  the  subparts  of  the  motor  should  also  be 
scaled  down  without  violating  the  other  constraints,  such  as  the  minimum  clearance 
between  the  brushes  and  the  commutator  rings. 

Components  are  also  used  to  group  constraints  into  different  application 
sets.  All  components  (of  a constraint  object)  form  a constraint  set  speciGc  to  an 
application.  For  example,  the  Gow  control  valve  can  have  one  set  or  constraints  for 
design  and  a second  set  for  simulation.  These  sets  are  enabled  or  disabled  selectively, 
based  on  the  current  application.  If  the  parent  constraint  is  disabled  (by  setting  the 
DISABLE  Gag  in  the  F_start  event  to  YES),  then  all  the  component  constraints  are 
automatically  disabled. 

5.4.-I  Connection  Relations 

Connection  relations  partially  order  the  subconstraints  so  that  they  are 
invoked  in  a prespcciGed  order.  Unlike  the  connection  relations  (in  Chapter  3),  these 
relations  only  control  the  activation  of  the  subconstraint  objects  (they  do  not 
transmit  values  among  subconstraint  objects).  The  values  needed  by  the  subcon- 
straints are  retrieved  by  issuing  V_events  to  the  appropriate  structural  objects. 

In  general,  constraint  propagation  is  controlled  by  generation  of  D-e vents 
(l.c.,  driven  by  updates  to  data  in  the  structural  objects);  the  connection  relations,  on 
the  other  hand,  control  constraint  propagation  by  activating  the  subconstraint 
objects.  Note  that  connection  relations  govern  constraint  propagation  only  when  a 
constraint  object  delegates  constraint  checking  to  subconstraint  objects. 


i.5  Control  Mechanism  for  the  Const  mint  System 


The  connection  mechanism  for  the  constraint  satisfaction  system  is  based 
on  the  repeated  application  of  the  execution  cycle.  The  execution  cycle  is  the  funda- 


system.  The  design  of  the  execution  cycle  is  to  give  the  designer  maximum  control 
over  defining  of  events  and  deciding  the  nature  or  propagation  or  constraints  through 
the  system.  This  execution  cycle  is  divided  into  two  loosely  coupled  components-the 
data-driven  component  and  the  function-driven  component.  The  data-driven  com- 
ponent is  initiated  by  the  D_events  (issued  by  the  structural  objects),  and  the 
function-driven  component  takes  over  from  the  data-driven  component  by  issuing 
F-events.  Operationally,  the  execution  cycle  extends  the  interaction  cycle  of 
Chapter  3 (defined  by  the  Ml  and  M2  mappings)  by  including  a data-driven  com- 
ponent (defined  by  the  M3  mappings),  as  will  be  shown  below. 

The  execution  cycle  is  initiated  from  the  structural  objects  by  issuing 
D_events.  When  a D_event  b triggered,  the  system  attempts  to  activate  one  or  more 
constraint  objects  by  firing  F-start  events.  This  coupling  between  the  D_event  and 
the  constraint  object(s)  is  established  by  the  information  in  the  M3  mappings  (defined 
in  the  interaction  object,  described  earlier).  The  activation  rule  defined  in  the 


F_start  event  states  the  D-events  necessary  to  activate  the  constraint  objects.  When 
the  conditions  of  the  activation  rule  are  met,  the  system  places  a token  (i.e.,  a pair 
consisting  of  event  id  and  priority)  for  the  F-start  event  on  the  event-ready  queue. 
The  event  scheduler  uses  the  priority  of  these  tokens  to  determine  the  sequence  of 
triggering  for  the  F-start  events.  By  issuing  an  F-start  event  the  system  has  made  a 
commitment  to  functionally  analyze  the  data  that  caused  the  O-events. 


When  the  F-start  event  triggers,  the  data-driven  component  transfers  con- 
trol to  the  function-driven  component.  The  F_start  event  creates  an  activation 
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instance  for  the  constraint  object.  This  activation  instance  binds  to  the  relevant 
structural  objects,  whose  features  are  defined  as  the  external  features  of  the  con- 
straint object.  This  binding  is  based  on  the  coupling  information  held  in  the  M3 
mappings.  Binding  ensures  that  no  other  constraint  object  (or  functional  object)  can 
update  the  state  of  the  structural  object  during  this  execution  cycle.  The  activation 
instance  then  retrieves  the  relevant  feature  data  from  the  bound  structural  objects. 
Some  of  these  data  are  already  present  in  the  activation  instance  due  to  s_valucs 
returned  by  the  D_cvents.  Those  data  not  present  are  read  from  the  structural 
objects  by  issuing  V_events.  The  Events  use  the  coupling  information  held  in  the 
M3  mappings  to  get  to  the  relevant  features  in  the  hound  structural  objects. 

When  all  the  relevant  data  are  read  by  the  constraint  object,  the  TEST 
body  of  the  constraint  object  verifies  the  constraint  condition  and  produces  a set  of 
test  results.  These  test  results  and  the  variable  (of  the  structural  object)  that  trig- 
gered the  constraint  object  determine  the  set  of  ACTIONS  to  be  taken  by  the  con- 
straint object.  At  the  end  of  the  execution  of  these  actions,  the  new  values  for  these 
features  are  committed  to  the  structural  object,  or  the  initial  update  that  caused  the 
D_events  is  rolled  back  and  the  structural  objects  are  released  from  the  constraint 
objects.  At  this  point  the  F_end  event  destroys  the  activation  instance  of  the  con- 
straint objects.  This  completes  one  execution  cycle  of  the  control  mechanism  of  the 
constraint  system. 

The  execution  cycle  propagates  to  other  features  of  the  system  when  (a) 
there  is  at  least  one  feature  in  the  current  cycle  that  was  updated  by  the  ACTION 
part  of  the  constraint  object,  and  this  updated  feature  has  a set  or  alerters  which  can 
generate  D-events  (excluding  the  one  for  the  current  cycle);  or  (b)  the  constraint 
delegates  the  testing  to  subconstraints.  In  case  (a),  the  execution  cycle  repeats  for 
the  updated  features;  in  case  (b),  the  data-driven  component  of  the  execution  cycle  is 


omitted,  and  the  subconstraints  directly  bind  to  the  relevant  structural  objects  and 
then  issue  V_events  to  retrieve  the  data  needed  to  test  the  subconstraints. 

A complete  execution  cycle  is  explained  with  the  temperature  monitoring 
and  control  system  example  shown  below.  Let  us  assume  an  SF  model  for  this  exam- 
ple in  terms  of  D-events,  F_events,  and  V_events  such  that 

(1)  There  are  two  structural  objects,  FAN  and  ENGINE,  with  state  variables  fan 
speed  and  temperature,  respectively. 

(2)  An  alerter  defined  on  the  variable  temperature  signals  a D_event  VI  if  the 
engine's  temperature  crosses  a threshold,  TI. 

(3)  An  alerter  defined  on  the  variable  fan  speed  sigunls  :i  D-event  V2  if  the  fan 
speed  changes  by  5 percent  or  more  of  its  current  value  or  if  the  fan  shuts  down. 

(4)  An  F_start  event  activates  a constraint  object  "temperature  control,  TC“  if 
cither  D_event  occurs.  The  IF  part  of  the  activation  rule  is  denoted  as  VI  OR  V2. 

(5)  A constraint  object,  temperature  control,  TC,  that  consists  of  (a)  a TEST  condi- 
tion between  the  current  temperature,  current  fan  speed,  optimal  temperature  and 
desired  fan  speed;  and  (b)  an  ACTION  part  that  updates  the  fan  speed  as  the  tem- 
perature fluctuates  or  warns  the  user  that  the  fan  cannot  cool  the  system  down. 

(6)  An  F-end  event  that  deactivates  the  constraint  object  if  the  actions  in  (5)  are 
taken  or  if  the  user  manually  disables  the  warning  system. 

When  the  temperature  crosses  the  threshold,  the  alerter  on  temperature 
produces  a D_event,  VI.  This  D-event,  VI,  uses  the  M3  mapping  and  signals  the 
constraint  object,  TC.  The  activation  rule  of  TC  is  satisfied  (due  to  event  Vl)  and  a 
token  (i.e.,  the  id  and  priority  value  of  the  F_start  event)  is  placed  on  the  event- 
ready  queue.  When  the  token  moves  to  the  head  of  the  queue,  the  F_start  event  is 
triggered.  This  event  creates  an  activation  instance  for  TC.  The  activation  instance 
uses  the  Ml  mapping  to  bind  the  structural  objects  FAN  and  ENGINE  with  the 
activation  instance  of  TC.  The  temperature  of  the  engine  is  available  due  to  the 


s-value  returned  by  VI,  but  the  fan-speed  is  unknown.  Therefore,  the  activation 
instance  of  TC  issues  a V_event  on  fan-speed  and  reads  it  from  the  structural  object 
FAN  through  the  M2  mappings.  The  TEST  condition  in  TC  examines  the  condi- 
tions between  these  state  variables  and  executes  actions  to  change  the  fan-speed  or 
alert  the  user.  On  completing  these  actions,  the  new  value  of  fan-speed  is  commit 
ted  to  the  structural  object,  FAN.  The  structural  objects  FAN  and  ENGINE  are 
released  from  the  constraint  object,  TC,  and  the  F_end  event  is  triggered. 

Certain  things  become  obvious  in  this  example:  (a)  Each  constraint  has  a 
set  of  independent  variables  and  dependent  variables.  The  independent  variables,  in 
this  example,  the  temperature,  are  those  that  signal  D-events  to  the  constraint 
object.  The  dependent  variables,  in  this  example,  the  fan  speed,  are  those  that  have 
V_events  issued  against  them.  The  decision  as  to  whether  a variable  is  dependent  or 
independent  is  determined  at  run  time,  i.e„  by  the  arrival  of  D_events.  Note  that  in 


signals  a D-event,  V2,  (say,  due  to  a mechanical  failure  in  the  fan),  (b)  Variables  can 
be  strictly  declared  as  either  dependent  or  independent.  In  this  case,  the  F-start 
event  will  wait  for  a D-event  signal  (a  prespecified  waiting  time  can  be  defined)  from 
all  the  independent  variables  before  it  can  activate  a constraint  object,  (c)  V_events 
help  to  reevaluate  a D-event  in  light  of  new  information.  For  example,  the  cooling 
fan  can  signal  a D-event  by  stating  that  it  is  shutting  off;  as  the  current  temperature 
Is  low,  this  event  is  not  critical  and  is  ignored  by  the  system.  Later  when  the  tem- 
perature crosses  the  threshold,  this  D-event  information  is  critical  and  the  system 
retrieves  the  information  through  a V_event.  So,  V-evcnts  can  be  regarded  as 
D-events  that  are  brought  back  to  life  because  they  are  needed  to  determine  actions 
in  light  of  the  new  system  state. 
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5.6  Role  of  the  Execution  Cycle  and  Interaction  Cycle 

There  15  0 major  difference  in  the  control  strategy  of  the  interaction  cycle 
(section  3.4)  and  the  execution  cycle  described  in  section  5.5.  The  interaction  cycle  is 
functionally  driven,  i.e.,  the  functional  model  (of  the  SF  paradigm)  govern  how  the 
system  responds  to  an  Input  stimulus  by  selectively  activating  one  or  more  functional 
objects.  The  structural  objects  simply  record  these  changes  as  updates  to  the  struc- 
tural features.  Intuitively,  it  is  similar  to  an  application  program  that  updates  the 
data  values  held  in  a data  structure.  The  execution  cycle,  on  the  other  hand,  is 
structurally  driven,  i.e.,  the  updated  data  values  in  the  structural  objects  (of  the  SF 
paradigm)  governs  how  the  system  responds  to  a change  in  state.  The  constraint 
object  responds  to  the  D-events  and  F-events  by  either  updating  or  rolling  back  the 
current  value.  (It  should  be  noted  that  the  execution  cycle  is  not  purely  data  driven 
because  a parent  constraint  object  can  selectively  activate  subconstraint  objects  and 
bypass  the  data-driven  component  of  the  execution  cycle).  A versatile  system  should 
integrate  both  these  execution  strategies  into  one  comprehensive  framework. 

Figure  5.1  presents  an  architecture  of  such  an  integrated  system.  The 
structural  objects  interact  with  the  functional  objects  and  the  constraint  objects  by 
the  Ml,  M2,  and  M3  mappings.  For  the  interaction  cycle,  the  system  updates  its 
state  by  using  the  activation  rules,  deactivation  rules,  and  Ml  and  M2  mappings. 
For  the  execution  cycle,  the  alerters  generate  D-events  which  trigger  F-events  by 
using  the  coupling  information  in  the  M3  mappings.  These  F-events  activate  the 
constraint  objects  which  use  the  coupling  Information  in  the  M3  mappings  to  update 
system  state. 
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Constraint  propagation  has  two  interpretations:  (a)  the  generation  of  new 
values  from  a set  of  existing  values  by  using  a fixed  set  of  constraints  (SUS80, 
KUI84);  and  (b)  the  generation  of  new  constraints  based  on  existing  constraints 
(STE81).  In  this  work,  we  only  consider  the  first  definition  of  constraint  propagation. 

Propagation  of  new  values  in  the  system  is  determined  by  the  Constraint 
Graph,  CG.  A constraint  graph  is  a directed  hypergraph  that  shows  the  propagation 
structure  that  updates  the  features  or  the  system.  A hypergraph,  HG(N,  A)  is  an 
ordered  pair  of  a set  of  nodes,  N,  and  a set  of  hyperarcs.  A,  where  each  hyperarc 
consists  of  a set  of  nodes.  Each  node  is  a feature  and  each  hyperarc  is  a constraint 
object  defined  over  the  set  of  features.  For  ease  of  notation,  we  denote  (ABCD, 
{ABC,  BCD})  a hypergraph  with  nodes  (features)  A,  B,  C,  and  D and  hyperarcs 
(constraints)  ABC  between  nodes  A,  B,  and  C,  and  BCD  between  nodes  B.  C,  and  D. 

A directed  hypergraph,  DHG(N,  DA)  is  a graph  of  nodes,  N,  and  a set  of 
directed  hyperarcs.  DA,  which  consists  of  an  ordered  pair  of  node  sets.  For  example, 
the  directed  hypergraph  (ABCDE,  {{A,  {BC}},  {CD.  {E}}»  consists  or  nodes  A,  B,  C, 
D.  and  E and  one  hyperarc  from  node  A to  nodes  B and  C,  and  a second  hyperarc 
from  nodes  C and  D to  node  E.  The  first  set  of  the  ordered  pair  (of  the  hyperarc) 
contains  the  tail  nodes,  and  the  second  set  of  the  ordered  pair  contains  the  head 
nodes.  In  the  first  hyperarc  above,  namely  {A,  {BC}},  node  A is  the  tail  node,  and 
nodes  B and  C are  the  head  nodes. 

The  nodes  at  the  tail  of  the  arc  represent  those  features  that  invoke  the  M3 
mappings,  i.e.,  the  features  that  issue  the  D-events.  and  the  nodes  at  the  head  of  the 
arc  are  those  features  that  are  updated  by  the  constraint.  In  this  system,  we  note 
the  following:  (a)  the  features  that  issue  the  D-evenls  are  not  modified  by  the  actions 
constraint;  if  they  arc  to  be  modified,  then  the  system  rolls  back 


associated  with  the 


against  them;  and  (c)  actions  update  only  a subset  of  V_event  features.  These 


When  two  or  more  hyperarcs  share  at  least  one  common  node  (i.e.,  when 
there  exists  a connected  hypergraph),  we  say  that  values  propagate  among  con- 
straints. For  example,  the  arcs  DA1:{A,  {BC}}  and  DA2:{C,  {DE}}  have  a node  C in 
common  and  therefore  form  a connected  graph.  A feature  value  propagates  among 

head  node  in  at  least  one  constraint  and  as  a tail  node  in  at  least  one  constraint.  In 
this  example,  the  constraint  corresponding  to  DAI  is  executed  before  constraint  DA2 
because  the  common  node  C is  in  the  head  of  DAI  and  in  the  tail  of  DA2.  After 
constraint  DAI  commits  its  actions  to  the  structural  objects,  constraint  DA2  is 
activated  in  the  next  execution  cycle  due  to  the  D_event  generated  on  node  C. 

The  structure  of  the  constraint  graph  determines  the  type  of  constraint  pro- 
pagation path.  There  are  three  types  of  propagation  paths:  constraint  tree,  con- 
straint DAG,  and  constraint  cyclic  graph. 


Constraint  tree.  The  ar 
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common  with  the  head  nodes  of  only  one  other  arc,  and  there  exists  only  one  arc 
whose  tail  has  no  common  node  with  any  other  head  nodes.  For  example, 
(ABCDEF,  {{A,  {BCD}),  {BC.  {E}},  {CD,  {F}}»  represents  a constraint  tree  with 
three  constraints,  Fl,  F2.  and  F3,  denoted  by  the  hyperarcs  {A,  {BCD}},  {BC.  {E}}, 
and  {CD,  {F}},  respectively,  and  these  constraints  are  defined  over  the  features  A,  B, 
C,  D,  E,  and  F (see  Figure  5.2).  The  structure  of  the  tree  has  constra 
with  constraints  F2  and  F3  as  its  children.  When  the  feature  A is 
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Figure  5.2 


Constraint  tree  with  no 
FI,  F2,  and  F3.  Tail  nc 
by  single  lines. 


s A.  B,  C.  D,  E,  and  F,  and  with  hyperarcs 


Figure  5.3 


Constraint  DAG  with  nodes  A,  B,  C,  D,  E,  and  F,  and  with  byperares 
Fl,  F2.  F3.  and  Fl.  Tail  nodes  are  shown  by  double  lines,  and  head 
nodes  by  single  lines. 
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updates  the  features  B,  C,  and  D.  The  D_evems  on  B.  C,  and  D use  the  relevant  M3 
mappings  to  invoke  constraints  F2  and  F3,  which  results  in  updating  E and  F, 
respectively.  Therefore,  an  update  on  A propagates  to  B,  C,  D,  E,  and  F by  con- 

Constraint  DAG.  The  arcs  are  partially  ordered  so  that  no  directed  cycles 
exist  among  the  features.  The  constraint  tree  automatically  satisfies  this  condition. 
For  example,  (ABCDEF,  {{A,  {BCD}},  {BC,  {E}},  {CD,  {E}},  {E,  {F}}})  represents  a 
constraint  DAG  with  four  constraints  FI,  F2,  F3,  and  F4  denoted  by  arcs  {A, 
{BCD}},  {BC,  {E}},  {CD.  {E}},  {E.  {F}},  respectively  (see  Figure  5.3}.  The  structure 
of  the  constraint  DAG  has  constraint  FI  as  root  with  constraints  F2  and  F3  as  chil- 
dren of  Fl,  and  constraints  F2  and  F3  are  parents  of  constraints  F4.  The  value  for 
the  feature  E in  constraint  F4:{E,  {F}}  is  computed  two  times-once  by  F2:{BC,  {E}} 
and  then  by  F3:{CD,  {E}}.  Here,  a feature  is  subject  to  more  than  one  value  during 
constraint  propagation,  and  the  system  picks  the  appropriate  value  by  conflict  reso- 
lution. The  conflict  resolution  routine  is  expressed  declaratively  as  the  ON  condition 
in  the  alerter  construct.  If  the  two  values  arc  consistent,  the  D_event  generates  a 
STABLE  signal  and  the  propagation  continues  normally.  If  the  values  are  incon- 
sistent, the  D-event  generates  an  ASTABLE  signal  which  will  cause  the  system  to 
abort  the  transaction  or  take  corrective  actions.  As  these  values  will  not  necesarily 
arrive  simultaneously,  this  is  a memory-based  alerter.  The  D_event  will  signal  either 
the  MINimum,  MAXimum,  AVErage,  DIFFerence,  or  an  user  defined  value  as 
defined  by  the  s— value  in  subsection  5.3.1. 1. 

A simple  example  is  an  alerter  condition  which  generates  a stable  D-event 


x:  real, 

EVENT:  Vi 

{ 

ALERT: 

STABLE:  Interaction_obiect.M3_name_l: 

ON:AVE(x,  |tl ..  t2]) 

ASTABLE:  Interaetion_object.,VI3_name_2' 

ON:  (x,  t) 

j WHEN  (x,  l)  < 100; 

Constraint  C..I.  C|,li.  T1,  |mnl 

with  cycles  where  the  new  feature  value  depends  on  its  previous  value.  This  is  the 
most  general  case  and  Includes  both  the  constraint  tree  and  the  constraint  DAG. 
Here  a feature's  value  is  computed  many  times,  and  this  value  depends  on  the  previ- 
ous value  of  the  feature.  The  constraint  system  assures  stability  (i.c„  the  system  will 
become  consistent  after  a finite  number  of  executions  of  the  execution  cycle)  by  exa- 
mining if  the  new  value  of  the  feature  satisfies  the  stability  condition  specified  by  the 
ON  eondition  of  the  D_event.  If  it  does,  constraint  propagation  is  allowed  to  con- 
tinue by  signaling  a STABLE  D_event;  otherwise  the  system  complains  to  the  user 
(or  calls  an  exception  handling  routine)  about  the  violation  and  aborts  the  propaga- 
tion by  signaling  an  ASTABLE  D_event.  For  example,  (ABCDEF,  {A,  {BCD}}, 
{BC,  {E}},  {CD,  {F}},  {F,  {A}})  represents  a constraint  graph  with  four  constraints 
FI,  F2,  F3,  and  F4  denoted  as  arcs  {A,  {BCD}},  {BC,  {E}},  {CD,  {F}},  and  {F,  {A}}, 
respectively  (see  Figure  5.4).  The  structure  of  the  constraint  graph  contains  a cycle 
between  the  hyperarcs  F1:{A,  {BCD}},  F3:{CD,  {F}},  and  F4:{F,  {A}}.  An  update  to 
feature  A propagates  to  C,  D,  F,  and  back  to  A.  Stability  conditions  are  important 
for  those  features  that  actively  participate  in  the  cycle,  i.e„  those  features  that 
depend  on  their  old  values,  in  this  case.  A,  C.  D,  and  F.  (Note  that  the  other  vari- 
ables, namely  B and  E,  are  also  recomputed  in  each  cycle,  but  these  values  do  not 
influence  the  propagation  cycle).  It  is  cast-  to  verify  that  the  tail  nodes  of  the 
superarcs  that  participate  in  the  cycle  are  directly  responsible  for  recomputing  new 
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values  for  all  the  nodes  in  the  cycle.  As  in  the  constraint  DAG  case,  the  D-evonts  are 
memory-based.  The  stability  conditions  in  the  D-events  arc  defined  by  the  WHERE 
and  WHEN  statements  of  the  ON  condition. 

An  example  specifying  stability  conditions  in  a D_event  on  feature  x that  is 
stable  only  if  its  value  increases  for  T seconds  and  then  remains  within  2 percent  of 
its  value  is  stated  as 


ALERT: 

STABLE:  li 
ON:  (x,l) 


tion-object.M3_name— : 


AST  ABLE:  Interaction-object.M3_name-2: 

WHEREte*U)  > (x,  tl-1); 

WHEN  (x,  tl)  <T; 

AND 

™ T)  OR  (It- t2)  - T): 


This  condition  describes  the  dynamic  piee 


The  above 
by  simple 


the  behavior  is  within  limits  defined  by  the  STABLE  D_events;  otherwise,  the  system 
will  trigger  ASTABLE  D_events  which  can  either  cause  the  execution  to  terminate 


or  to  take  corrective  actions  as  defined  by  the  action  part  of  the  constraint  object. 
These  constructs  give  the  database  the  power  to  monitor  and  control  the  future 
behavior  of  the  features  in  a complex  system  and  to  take  corrective  actions  if  the  sys- 
tem deviates  from  its  prescribed  behavior. 


5.8  Analyzing  Propagation  Structures 
There  are  two  ways  of  controlling  constraint  propagation:  (a)  to  detect 
cycles  during  run  time  and  then  terminate  the  cycle  after  a fixed  number 


of  cycles; 


and  (b)  to  estimate  the  type  of  propagation  path  before  constraint  satisfaction  begins 
and  isolate  those  features  whose  values  are  critical  in  successfully  terminating  the 
propagation.  This  section  describes  how  to  construct  propagation  paths,  determine 
the  types  of  propagation  paths,  and  analyze  the  paths  to  control  constraint  propaga- 


As  noted  earlier,  there  are  three  types  of  propagation  paths:  tree.  DAG, 
and  cyclic  graphs.  For  a tree,  propagation  starts  at  the  root  and  terminates  at  the 
leaves,  and  each  feature  is  computed  only  once.  For  a DAG,  propagation  starts  from 
many  roots  and  terminates  at  the  leaves,  but  there  are  features  whose  values  are 
computed  many  times;  the  number  is  equal  to  the  distinct  paths  that  lead  to  the 
feature.  For  a cyclic  graph,  propagation  starts  at  one  or  more  points  and  may  never 
terminate  due  to  its  recursive  nature. 


The  structure  of  the  propagation  path  is  determined  by  the  distribution  of 
the  D-events  and  the  V_evcnts  over  the  features  in  the  constraints.  Within  a con- 
straint, the  direction  of  propagation  is  from  the  features  that  issued  the  D_events  to 
the  features  that  have  V_evenls  issued  against  them.  Among  constraints,  the  direc- 
tion of  propagation  is  from  the  constraint  that  issued  the  V_event  to  the  constraint 
that  issued  a D-event  on  the  same  (i.e.,  common)  feature. 

Entg.  point.  An  entry  point  for  a set  of  constraints  is  a feature  (belonging 
to  this  constraint  set)  that  issues  an  D-evcnt  when  its  ON  conditions  are  satisfied  by 
values  supplied  from  outride  the  constraint  set.  For  example,  during  a design  process 
when  the  engineer  changes  the  diameter  of  the  spindle  manually,  the  spindle  diame- 
ter  becomes  the  entry  point  of  the  constraint  set  relating  the  diameters  of  the  spin- 
dle, sealing  bush,  bearing  bush,  and  the  housing. 

Entry  point  closure.  Entry  point  closure  is  the  set  of  all  constraints  in  the 
propagation  path,  starting  from  one  entry  point.  These  constraints 
depth-first  manner  in  the  direction  of  constraint  propagation. 
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Computing  entry  point  closure.  Let  A be  the  entry  point. 

(a)  Determine  the  set  of  constraints  related  to  A from  the  M3  mappings.  Place  these 
constraints  in  the  closure  set,  C.  If  the  D-svent  for  A can  directly  activate  a con- 
straint in  C.  mark  this  constraint  as  live;  if  the  D-event  for  A cannot  directly 
activate  (i  a,  needs  other  features  in  addition  to  A)  a constraint  in  C,  mark  this  con- 
straint os  dormant . Do  this  for  all  constraints  in  C. 

(b)  For  each  live  constraint  in  the  closure  set,  determine  the  features  which  issue 
V_events. 

(c)  Issue  D-events  (without  checking  the  ON  condition)  for  the  features  in  (b)  and 
go  to  step  (a)  to  determine  the  constraints  associated  with  these  features. 

(d)  Repeat  until  no  more  constraints  are  added  to  the  set. 

The  entry  point  closure  has  the  following  properties:  (a)  the  closure  set  has 
a structure.  i.e.,  it  is  either  a constraint  tree,  DAG,  or  a cyclic  constraint  graph;  and 
(b)  structure  of  the  closure  set  of  live  constraints  is  a superset  of  the  run  time  propa- 
gation path.  The  entry  point  closure  enumerates  all  possible  paths  through  which 
the  propagation  can  proceed  during  constraint  satisfaction,  as  the  ON  conditions  of 
the  D-events  are  not  evaluated  on  actual  data  values  from  the  structural  object. 

We  will  now  present  a general  algorithm  to  determine  the  type  of  structure 
of  the  closure  set. 

(a)  Compute  the  entry  point  closure. 

(b)  If  each  live  constraint  appears  only  once  in  the  closure,  the  propagation  path  is  a 

(c)  If  a live  constraint  (or  a set  of  live  constraints)  repeats,  it  is  either  a DAG  or  a 
cyclic  graph. 

(i)  If  the  repeating  set  is  contiguous,  it  is  a cyclic  graph.  The  propagation  path 
is  denoted  as  (x0* , where  a is  the  set  of  constraints  that  are  evaluated  only  once 
and  0 are  the  constraints  satisfied  several  times  during  constraint  propagation. 
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The  subset  of  0 represents  the  live  constraints  in  the  loop. 

(ii)  If  each  set  of  repetitions  is  separated  by  at  least  one  other  live  constraint, 

the  propagation  path  is  a DAG  and  is  denoted  by  a0(0 where  a,  {,  ...  are 

the  set  of  constraints  that  are  evaluated  only  once,  and  0 is  a set  of  constraints 
that  can  be  reached  from  multiple  paths  in  the  DAG.  There  are  several  such  0 
in  a DAG. 

An  efficient  algorithm  to  detect  a tree,  DAG,  or  cyclic  graph  is  given 
below.  Label  each  constraint  by  a pair  of  numbers:  the  constraint  id  and  the 
sequence  number  that  marks  its  position  in  the  propagation  path.  Compute  the  clo- 
sure of  the  entry  point  and  hash  each  live  constraint  on  its  constraint  id  number. 
Ensure  that  each  unique  constraint  id  hashes  to  a different  bucket.  If  there  is  only 
one  entry  per  bucket,  the  propagation  path  is  a tree.  If  more  than  one  constraint 
hashes  to  the  same  bucket,  the  closure  is  either  a DAG  or  cyclic  graph.  Contiguous 


sequences  indicate  that  the  propagation  path  is  a cyclic  graph.  If  the  third  sequeuce 
number  in  a bucket  does  not  satisfy  the  above  condition,  then  the  constraint  propa- 
gation path  is  a DAG.  The  number  of  entries,  n,  per  bucket  for  a DAG  structure 
corresponds  to  the  number  of  propagation  paths  to  the  feature.  This  implies  that  the 
feature  (corresponding  to  the  bucket)  will  have  its  value  computed  n times  during 
constraint  propagation.  Do  this  until  the  closure  set  is  fully  computed  or  there  are  at 
least  three  entries  in  the  bucket  that  satisfy  the  contiguous  condition  test  (for  cyclic 
graphs). 

After  establishing  the  structure  of  the  closure  set,  it  is  necessary  to  detect 
these  constraints  that  receive  multiple  values  for  their  features.  The  algorithm  for 


constraint sequences  are  detected  when  the  sequence  number  of  the  second  value  in  a 
bucket  is  the  arithmetic  mean  of  the  third  value  and  the  first  value.  Contiguous 


doing  this  is  presented  below: 
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(a)  Closure  for  the  entry  point  A is  a tree:  There  is  no  sueh  constraint  according  to 
the  deBnition  of  the  constraint  tree  given  earlier. 

(b)  Closure  for  the  entry  point  A is  a DAG:  Let  the  closure  for  entry  point  A be 
represented  as  00(0...  The  constraints  in  the  repeating  set,  i.e.,  ft  have  features 
whose  values  are  computed  several  times,  each  time  by  the  set  of  constrainls  a,  (, .... 
These  constraints  in  0 correspond  to  those  buckets  that  have  more  than  one  entry. 

(c)  Closure  for  the  entry  point  A is  a cyclic  graph:  Let  the  closure  for  entry  point  A 
be  represented  as  a0 *.  The  set  of  constraints  in  0 have  features  that  are  computed 
several  times.  These  constraints  are  obtained  as  in  (b)  above. 

After  detecting  the  set  0,  the  system  determines  the  nodes  that  will  receive  mul- 
tiple values.  These  nodes  correspond  to  the  tail  nodes  of  the  constraints  in  0 and  are 
given  by 

N - {n  | n - {Toil,.},  ft  - <{7aft},  {Hcad,}>,  ft  f 0) 

Now,  the  D-events  for  nodes  in  N should  have  suitable  memory  based  alerters 
defined  on  these  features  to  ensure  that  the  system  reaches  a consistent  state  after  a 
finite  number  of  execution  cycles. 

So  far  we  considered  only  closures  of  single  entry  points.  In  real  world 
applications,  more  than  one  feature  is  updated  by  the  designer,  giving  rise  to  multiple 
entry  points.  For  multiple  entry  points,  the  closure  for  each  entry  point  is  computed 
independently,  and  then  the  union  of  these  closures  is  determined. 

There  are  three  cases  for  integrating  closures.  Consider  two  closures,  pi 
and  p2,  determined  from  entry  points,  A1  and  A2,  respectively. 

CsseiaJ.  pi  INTERSECT  p2  - NULL,  then  (a)  the  two  closures  do  not 
share  any  internal  nodes;  (b)  there  are  no  external  constraints  that  connect  the  nodes 
of  the  two  closures;  and  (c)  new  constraints  are  added  to  the  closure  of  the  union  of 
pi  and  p2  only  if  both  pi  and  p2  have  common  dormant  constraints. 


The  two  clc 


straints  are  added  to  the  closure  of  the  union  of  pi  and  p2  only  if  both  pi  and  p2 
Proof  for  (i)  is  directly  obtained  from  the  definition  of  the 

Therefore,  a multipie-entry-point  system  is  (a)  the  superimposition  of  rr 
added  to  the  closure  of  the  union  of  pi  and  p2  only  if  they  share  common  dorr 


sraph.  Proof 
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; closure  of  the  union  of  pi 
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independently  trigger  the  F-event  of  the  dormant 
sures  are  integrated,  these  dormant  constraints  become  live  if  the  D_e. 
complement,  the  D_events  of  p2  (or  vice  versa)  to  fire  the  Fjvent.  This  condition 
is  the  efficient  condition  for  adding  live  constraints  to  the  closure  of  the  union  of  pi 
and  p2.  This  condition  can  be  generalized  to  any  number  of  candidate  closures,  pi, 


pn,  such  that  each  unique  constraint  id  corresponds  to  one  set.  For  each  set  take  the 
compute  the  closure  of  this  set. 

These  results  enable  the  system  to  analyze  complex  constraint  networks 
before  run  time  by  analyzing  single-entry  closures  and  then  combining  these  closures 
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and  run  the  data  against  this  partially  defined  propagation  path.  This  is  useful 
because  the  actual  data  will  not  trigger  all  the  D-events,  in  which  case  the  propaga- 
tion paths  starting  from  the  feature  that  failed  to  generate  D-ovents  can  be  pruned 
from  the  closure  set. 

The  next  chapter  discusses  two  applications  of  the  SF  paradigm.  In  the 
first  example,  the  SF  paradigm  is  used  to  select  components  in  the  design  of  a robotic 
workcell;  in  the  second  example,  a computer  integrated  manufacturing  environment 
is  proposed  in  which  the  SF  paradigm  is  used  to  integrate  databases  and  application 
programs. 


APPLICATIONS  OF  THE  STRUCTURE-FUNCTION  PARADIGM 

6.1  Introduction 

This  chapter  presents  applications  d the  SF  paradigm  to  the  engineering 
domain.  The  first  application  is  the  design  of  robotic  workceiis.  The  designer 
specifies  a high-level  task  description  of  the  workcell.  By  using  the  structural  and 
functional  knowledge,  the  system  breaks  down  this  description  into  a sequence  of 
low-level  functional  tasks,  and  guides  the  designer  through  the  design  by  using  struc- 
tural and  functional  contexts  to  reduce  design  choices.  In  the  second  application,  the 
SF  paradigm  is  used  to  integrate  application  programs  and  databases  in  a computer 
integrated  manufacturing  (CM)  environment.  Here,  an  overall  CIM  architecture  is 
proposed  for  a globally  distributed  engineering  database  system. 

6.2  Workcell  Design 

Chapter  3 proposed  that  the  separation  of  structures  from  functions  is  a 
powerful  knowledge  representation  paradigm.  To  fully  use  this  power,  the  structural 
and  functional  information  should  have  well-defined  knowledge  structures,  i.e.,  either 
a generalization  or  aggregation  hierarchy  (or  DAG).  This  section  shows  that  a well- 
defined  knowledge  structure  for  structural  objects  and  functional  objects  increases 
the  power  of  this  paradigm. 

During  design,  the  system  should  select  among  the  alternative  structures 
and  functions  found  in  interaction  types  (ii)  of  section  3.3.2.2,  (ii)  of  section  3 .3.2.3, 
and  (iii)  of  section  3.3.2.3.  This  selection  is  done  by  defining  contexts.  There  are 
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two  types  of  contexts  based  on  the  type  of  abstractions  in  the  structural  and  func 
tional  domains.  The  first  context  type  is  based  on  the  aggregation  hierarchy  (DAG) 
for  the  structural  and  functional  objects.  The  second  context  type  is  based  on  the 
generalization  hierarchy  (DAG)  for  the  structural  and  functional  objects.  This  sec- 
tion analyses  both  context  types. 

For  sake  of  discussion,  call  the  set  of  alternative  structural  objects  (of  a 
function)  as  M_structural  objects,  and  the  set  of  alternative  functional  objects  (of  a 
structure)  as  M-functional  objects.  The  structural  context  is  used  to  select  a struc- 
tural object  from  a set  of  M-structural  objects;  the  functional  context  is  used  to 
select  a functional  object  from  a set  of  M-functionai  objects. 

6.2.1  Context  Based  on  Aggregated  Ohieri* 

Contexts  can  be  predicated  on  structural  adjacency,  i.e.,  by  structural  con- 
texts; on  functional  precedence,  i.e.,  by  functional  contexts;  or  on  causal  actions 
which  are  based  on  the  type  of  inputs  to  and  outputs  from  a function.  In  this  work, 
structural  context  is  narrowly  defined  as  (a)  having  the  same  parent  structural  object, 
and  (b)  being  physically  adjacent.  This  definition  is  used  for  selecting  among  alterna- 
tive structural  objects  in  interaction  type  3.(iii). 

Structural  contexts  arc  meaningful  because  an  update  to  a physical  com- 
ponent (of  a system)  will  propagate  to  other  components  by  Bret  influencing  its 
immediate  neighbors.  A context  is  tailored  to  fit  the  requirements  of  the  application 
domain  by  defining  appropriate  selection  predicates.  A selection  predicate  holds  the 
context  information  needed  to  pick  a unique  structural  object  from  a set  of 
M_structural  objects. 

A selection  predicate,  /f(q,  r),  is  an  ordered  pair  of  sets  that  are 
c-functional  on  q;  i-e.,  for  a set  of  structural  objects,  q,  which  are  in  the  receiving 
mode  there  exists  a unique  set  of  M_structural  objects,  r.  such  that  c is  the  context 
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within  which  both  q and  r are  defined.  For  example.  (gate-1,  gale_2)  is  a 
selection  predicate  that  states  if  gate_l  is  in  the  receiving  mode,  then  gate-2  will  be 
in  the  receiving  mode  in  the  next  interaction  cycle,  and  that  gate_l  and  c.».  ? are 
subcomponents  of  the  structural  object.  circuit_l.  The  next  few  paragraphs  show 
that  selection  predicates  exist  for  M-structural  objects  in  a structural  hierarchy. 

Statement,  if  alternative  structural  objects  (M_structural  objects)  are 
arranged  in  structural  hierarchies,  then  a functional  object  can  uniquely  select  the 
appropriate  structural  object  by  using  selection  predicates. 

Sffilanat'°"-'  Let  s - S*  Sj}  represent  a set  or  nodes  in  the  struc- 
tural hierarchy.  Now,  S is  a set  whose  elements  are  pair-wise  disjoint.  This  is  true 
because  each  element  represents  a set  of  children  nodes  indexed  by  the  parent  node 
of  a hierarchy  of  structural  objects.  Let  us  examine  three  cases  that  define  the 
semantics  of  the  selection  predicate. 

Straataral  objects  q and  r have  the  same  parent  structural  object. 
Let  q represent  a structural  object  in  the  receiving  mode  and  r represent  a 
M-structural  object,  i.e„  r e U S.  Construct  a predicate,  /t(q,  r),  where  f.  Is 
c-functional  on  q,  and  the  structural  objects  q and  r are  the  children  of  structural 
object  c.  Semantically,  the  ordered  pair  <q,  r>  is  constructed  so  that  q is  adjacent 
to  r,  i.e.,  the  output  external  features  of  q are  directly  connected  to  the  input  exter- 
nal features  of  r. 

Ca5e  M structural  objects  q and  r belong  to  different  parents  m and  n, 
respectively.  The  selection  predicate  on  q and  r is  determined  by  finding  a common 
ancestor,  c,  which  establishes  a physical  adjacency  (i.e.,  the  assembly  relations)  rela- 
tion between  q and  r.  The  common  ancestor,  c,  is  guaranteed  to  exist  only  if, 
according  to  the  external  feature  preservation  invariant  (section  4.2),  the  subset  of 
the  external  features  of  the  structural  objects  q and  r are  the  external  features  of  all 
the  structural  objects  along  the  path  from  q and  r to  the  common  ancestor,  c. 
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The  two  axioms  (Al)  and  (A2)  below  state  the  semantics  or  the  selection 

predicate: 

(AI)  /c(<t>  r)  — /c(q>  rl)  and  /, (q,  r2)  if  and  only  if  rl  - r2. 

(A2) If  /»( P.  q).  /„(r,  s),  and  /,(m,  n)  then  /c(q,  r) 

Axiom  (Al)  says  that  /r(q,  r)  is  c-functionai  on  q as  required  in  the  simple 
case:  axiom  (A2)  is  a recursive  axiom  to  derive  selection  predicates  from  existing 
predicates  by  assigning  a common  ancestor  to  objects  q and  r.  For  A2  to  be  true, 
the  external  features  of  q and  r should  also  be  the  external  features  of  m and  n, 
respectively. 

In  real  world  applications,  an  object  in  the  receiving  mode  can 
potentially  influence  many  (all)  of  its  neighboring  fcLstruetunU  objects.  For  example, 
when  the  input  values  to  the  CARRY  circuit  in  Figure  2.8a  are  present,  three  physi- 
cal instances  of  the  AND  gate  are  simultaneously  activated  in  the  next  interaction 
cycle.  This  case  is  represented  by  extending  the  selection  predicate  definition 
without  losing  any  of  the  representation  power  shown  earlier.  To  model  this  case, 
axiom  (Al)  becomes 

/e(q,  r)  is  ^-functional  on  structural  object  q upto  a partial  temporal  order. 

A predicate  /e(q,  r)  is  c functional  up  to  a partial  order,  if  each  structural 
object,  q,  uniquely  identifies  a set  of  structural  objects,  r,  such  that  all  elements  of  r 
have  a partial  temporal  order.  Formally, 

(A3)  /,(q,  r)  — /t(q,  rl)  and  /t(q,  r2) 

if  and  only  if  (i)  rl  = r2,  or  (ii)  rl  !=  r2  and  rl  <,  r2 

Here,  <,  is  the  partial  temporal  order  and  !=  denotes  not  equal.  The  simultaneous 
activation  of  the  three  AND  gates  of  the  CARRY  circuit  in  Figure  2.8a  is  an  exam- 
ple of  a partial  temporal  order. 
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Existence  of  a selection  predicate  in  a structural  DAG.  To  generalize  the 
above  result,  it  is  necessary  to  show  that  a M_structurai  object  in  a structural  DAG 
can  be  uniquely  assigned  to  an  activation  instance  of  a functional  object. 

?l'"emenl-  Given  a set  of  non-empty  overlapping  sets  (i.e.,  sets  not  pairwise 
disjoint)  show  that  there  exists  a selection  predicate  % r)  that  can  uniquely  pick  out 
a M_structura!  object. 

The  proof  consists  of  showing  that  f(q,  r)  is  equivalent  to  /t( q,  r). 
This  is  done  in  two  parts:  (a)  show  that  the  selection  predicate.  f(q,  r),  on  a DAG 
implies  the  selection  predicate.  /c(q,  r),  on  a hierarchy;  and  (b)  show  that  the  selec- 
tion predicate  on  a hierarchy,  /f(q,  r),  implies  the  selection  predicate,  f(q,  r),  on  a 
DAG. 

Show  (a):  The  proof  is  straightforward  because  if  the  selection  predicate 
for  a DAG  of  structural  components,  f(q,  r),  is  definable  then  it  is  also  possible  to 
define  a selection  predicate,  /c(q,  r),  for  a hierarchy  of  components,  and  the  existence 
°f  /c(q,  r)  was  shown  earlier. 

Show  (b):  Let  n - {n„  ns, ....  n„}  represent  the  parent  structural  objects 
of  a set  of  M-structural  objects.  For  every  M-struetural  object,  construct  an 
ordered  pair  <n,-,  s{j>  where  n,  e n,  and  n,  is  the  parent  of  a,-,-.  Group  these  pairs 
into  sets  indexed  by  nf;  call  these  sets  S.  Now  generate  a predicate  instance  f[<m,-, 
ft->t  %>)  for  each  ordered  pair  where  p,  is  the  structural  object  that  is  in 
the  receiving  mode,  and  m;  is  the  parent  of  pf.  Therefore,  q - <m,-,  p,>,  and  r ■= 

It  is  apparent  that  the  sets  in  S are  pairwise  disjoint,  hence  showing  that 
the  selection  predicate  for  the  DAG  implies  the  selection  predicate  for  the  hierarchy. 
This  concludes  the  proof. 
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This  discussion  has  shown  that,  for  a finite  set  of  M_structural  objects  in  a 
well-defined  aggregation  structure  (i.e.,  hierarchical  or  DAG),  it  is  possible  to 
uniquely  assign  a function  to  a given  structural  object  by  selection  predicates.  By 
assigning  appropriate  semantics  to  the  selection  predicate,  fe  such  that  the  axiom  set 
presented  earlier  is  not  violated,  it  is  possible  to  define  structural-functional  interac- 
tions for  a physical  domain. 

6.2.2  Context  Based  on  Generalized  Objects 

This  subsection  shows  that  the  SF  paradigm  can  be  used  to  select  structural 
objects  and  functional  objects  from  a set  of  alternative  structures  and  functions  that 
is  arranged  in  a generalization  hierarchy.  We  will  demonstrate  this  by  using  a con- 
crete example  of  a robotic  workcell  to  assemble  circuit  boards.  A robotic  workcell 
consists  of  robots,  NC  machines,  cameras,  data  and  control  lines,  flux  pots,  solder 
pots,  component  bins,  etc.;  and  a set  of  functions  as  moving  a component,  picking  a 
component,  trimming  the  leads  of  a component,  soldering,  etc.  A workcell  is  used 
for  automating  well-defined  and  repetitive  tasks,  such  as  assembling  circuit  boards. 
Robotic  workcell  design  consists  of  selecting  workcell  components,  laying  out  these 
components  according  to  constraints,  and  simulating  the  layout  for  correctness  of 
operation  and  cycle  time.  The  structure-function  paradigm  is  used  in  robotic 
workcell  design  by  selecting  appropriate  workcell  components.  The  example  is  based 
on  an  actual  workcell  used  for  assembling  printed  circuit  boards  at  a company  in 
Florida.  For  completeness,  we  discuss  the  dictionary  structure  that  stores  workcell 
components,  and  then  show  how  the  design  system  uses  this  dictionary  to  guide  the 
designer  in  selecting  components  for  prototype  workcells. 

The  design  component  dictionary  consists  of  two  hierarchies:  one  for  the 
structural  objects  and  the  other  for  the  functional  objects.  These  hierarchies  are 
related  by  interaction  objects  which  associate  a set  of  structures  to  a function,  and  a 
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set  of  function  to  a structure.  These  interaction  objects  help  designers  to  examine 
alternative  structural  options  for  a given  functional  specification,  or  to  examine  alter- 
native applications  for  a given  structure. 

The  workcell  design  schema  also  consists  of  two  hierarchies  of  complex 
objects  that  are  aggregated  from  subobjects-a  structural  hierarchy  and  a functional 
hierarchy.  The  structural  hierarchy  represents  the  physical  configuration  of  the 
workcell,  e.g.,  the  layout  and  the  components.  The  functional  hierarchy  represents 
the  function  of  a workcell,  e.g.,  assembling  circuit  boards. 

The  design  component  dictionary  consists  of  three  classes  of  objects:  struc- 
tural objects,  functional  objects,  and  interaction  objects.  The  (subset  of)  structural 
objects  used  in  a robotic  workcell  design  is  shown  in  Figure  6.1.  These  objects  are 
arranged  in  a generalization  hierarchy  where  the  actual  objects  are  represented  in  the 
leaf  nodes,  and  the  internal  nodes  are  abstract  objects  that  classify  the  leaf  nodes. 
The  (subset  of)  functional  objects  used  in  robotic  workcell  design  is  shown  in  Figure 

In  Figure  6.2,  the  workcell  functions  consist  of  objects  that  PROCESS 
(manipulate)  a workpiece,  objects  that  HOLD  a workpiece,  and  objects  that  COM- 
MUNICATE in  the  workcell.  The  functional  object  PROCESS  is  an  F-AGG 
abstraction  of  the  functional  objects  TRANSFER  and  OPERATE,  i.e.,  to  process  a 
workpiece,  it  is  transferred  to  an  operating  area  and  then  operated  on.  TRANSFER 
is  an  F-GEN  abstraction  of  the  functional  objects  CARRY,  and  SLIDE,  i.e.,  an 
object  can  be  transferred  from  one  point  to  another  either  by  carrying  it  or  sliding  it 
(other  modes  of  transfer  not  shown  are  DROP,  and  ROLL).  CARRY  is  an  F-AGG 
abstraction  of  PICK.  MOVE,  and  PLACE.  SLIDE  is  an  F-GEN  abstraction  of  slid- 
ing FORWARD  or  sliding  BACKWARD.  These  functional  objects  are  a subset 
needed  for  an  actual  workcell  design,  but  are  sufficient  to  demonstrate  the  design 
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list)  for  robotic  workcell  design.  PUMA 


Figure  6.2  Fu 


objects  (partial  list)  for  robotic 
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The  interaction  objects  map  structural  objects  to  functional  objects.  Only 
example  Ml  mappings,  i.e.,  mappings  at  the  object  level,  are  shown.  The  set  of  Ml 

Figures  6.1  and  6.2  are 


m„:  < {TRANSFER},  OR{Electronic_Component,  Circuit_Board}> 

m15:  <OR{CARRY,  FORM,  TRIM,  SOLDER},  {Electronic_Component}> 

m,3:  < {CARRY},  AND{Robot,  Gripper,  Workpiece}> 

m14:  <{PICK},  OR{Kitting_Tray,  Exchange-Nest,  Test_Bench}> 

mI5:  <{MOVE},  OR{Space,  Former-Bench,  Flux_Pot,  Solder_Pot}> 

m,6:  < pLACE},  OR{Cutter,  Exchange-Nest,  Circuit_Board}> 

m„:  < {OPERATE},  OR{Electronic_Component,  Circuit-Board}> 

m,8:  < {SOLDER},  AND{Flux_Pot,  Soldcr_Pot}> 

m19:  <{TRIM},  {Cutter}> 

mu0:  <{FORM},  {Former_Bench}> 


number  of  structural  options  by  using  the  generalization  abstractic 
hierarchy  and  the  Ml  mappings.  Similarly,  functional  contexts 
number  of  functional  options  by  using  the  generalization  abstra 
tional  hierarchy  and  the  Ml  mappings. 

Electronic— Components.  An  Electronic-Component  has  many 
with  it  (see  Ml  mapping  mu).  The  system  should  decide  o 


ral  object.  Dup- 


owing  down  the 


OPERATE 
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OPERATE  on  the  Electronic-Component.  To  do  this,  the  system  uses  the  functional 
context,  in  this  case  OPERATE,  and  selects  only  those  actions  on  the 
Electronic-Component  that  correspond  to  OPERATE,  which  are  FORM,  TRIM, 
and  SOLDER  (but  not  CARRY). 

Let  functional  object,  f,  derive  a set  of  structural  objects,  S,  by  the  Ml 
mappings  and  a set  of  alternative  functional  objects,  {«}„  by  the  F-GEN  abstrac- 
tions. Let  S derive  a set  of  alternative  functional  objects  {f  i }2  through  the  Ml  map- 
pings. The  elements  of  {Fi}j  in  the  context  of  the  functional  object,  f,  i.e.,  {Ft};, 
are  given  by  {Ft'}/  - {Ft},  fl  (Fife.  Functional  contexts  narrow  the  alternate  func- 

than  one  common  element  in  {Ft},  and  {Fi}2. 

Using  the  above  example,  let 
f - OPERATE 

{Ft},  = FORM,  BEND,  TRIM.  MILL,  DRY.  SOLDER 

S - Electronic-Component 

{Ft},  = CARRY,  FORM,  TRIM,  SOLDER 

We  wish  to  OPERATE,  f,  on  an  Electronic-Component,  S.  Now,  the  set 

arc  CARRY,  FORM,  TRIM,  or  SOLDER,  {Ft  }2.  As  we  are  interested  in  OPERAT- 
ing  on  the  electronic  component  (i.e.,  the  context  is  OPERATE)  we  restrict  the  set 
of  actions  to  OPERATions.  The  possible  OPERATE  actions  from  the  functional 
hierarchy  (Figure  6.2)  are  FORM,  BEND,  SOLDER,  MILL,  DRY,  or  TRIM  actions, 
{Ft},.  Therefore  the  OPERATions  on  electronic  components  are  FORM,  TRIM,  or 
SOLDER,  {Fi}/,  which  is  obtained  by  taking  the  inteisection  or  {Ft},  and  {Ft},. 
Pictorially,  Figure  6.3  shows  the  construction  of  {Fi},  for  context  f.  The  object 
names  (for  the  above  example)  are  shown  beside  the  nodes. 
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FORM,  BEND,  ' • 
TRIM,  MILL.  {FiL 
DRY,  SOLDER  \ 


- TRIM,  SOLDER 


{pi},  n {fi)2 

FORM,  TRIM,  SOLDER 
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Structural  context.  Suppose  the  designer  is  designing  a part-handling  device 
and  has  decided  to  investigate  PICKing  actions.  Now,  a workpiece  can  be  PJCKed 
from  many  structural  devices  (see  mapping  mI4),  and  the  system  should  decide  on 
the  valid  devices.  To  do  this  the  system  uses  the  structural  context,  in  this  case 
Part-Handiing_Dcvice,  and  only  selects  the  structures  associated  with  PICK  that  arc 
of  the  type  Part-Handling-Device. 


A precise  description  of  structural  contexts  is  given  below.  Let  structural 
object,  s,  derive  a set  of  functional  objects,  F,  by  the  Ml  mappings  and  a set  of  alter- 
native structural  objects,  {Si}„  by  the  GEN  abstractions.  Let  F derive  a set  of  alter- 
native structural  objects  {SfJ,  through  the  Ml  mappings.  The  elements  of  {Si}2  in 
the  context  of  the  structural  object,  s,  i.e.,  {Si}„  are  given  by  {Si},  - {Si},  fl  {Si},. 


unique  structural  object,  as  there  can  be  more  than  one  common  element  in  {Si}, 
and  {Si},. 

Adding  a new  Ml  mapping  to  the  above  set, 
m,m:  <OR{PlCK,  STORE,  COLLECT}  {Part-Feeding-Devicc}> 


s — Part-Feeding-Device 

{Si},  = Kitting_Tray,  Exchange-Nest 

F = PICK 

{Si}j  = Kitting-Tray,  Exchange-Nest,  Test-Bench 

We  have  a Part-Feeding-Device,  s,  and  know  that  components  are 
PICKed,  F,  from  it.  Now,  a component  can  be  PICKed.  either  from  a Kitting-Tray, 
Exchange-Nest,  or  Test-Bench,  {Si}*  see  Ml  mapping  mH.  As  we  are  interested  in 
a Part-Feeding-Device,  which  is  the  context,  we  restrict  the  structures  associated 
with  PICK  to  Part-Fceding_Devices.  From  the  structural  hierarchy,  Figure  6.1,  a 
Part-Feeding-Device  can  be  either  a Kitting-Tray  or  an  Exchange-Nest,  {Si},. 


Therefore,  the  components  to  PICK  from  are  either  a Kitting_Tray.  or  an 
Exchange-Nest,  {Si},  which  is  obtained  by  taking  the  intersection  of  {Si},  and  {Si},. 
Pictorially,  Figure  6.1  shows  the  construction  of  {Si},  for  context  s.  The  object 
names  (for  the  above  example)  arc  shown  beside  the  nodes. 

The  Ml  mappings  along  with  the  generalization  abstractions  in  the  struc- 
tural and  functional  hierarchies  enable  the  system  to  store  multiple  options  and  to 
select  from  these  options  based  on  the  contexts.  The  separation  of  the  structural  and 
functional  information  into  distinct  but  semantically  related  domains  increases  the 
power  of  the  database  system  to  support  engineering  design  types  of  applications. 

6.2.3  Example-Design  of  Robotic  Wnrlnvlh 

Below  we  illustrate  how  the  SF  paradigm  uses  the  generalization  of  strut- 
tura!  and  functional  objects  and  the  interaction  between  structural  and  functional 
objects  to  design  a workcell  which  assembles  circuit  boards.  The  system  guides  the 
designer  through  the  design  process  by  selecting  the  structures  used  in  the  design  and 
presenting  alternative  design  choices.  The  fully  designed  circuit  board  assembly  sys- 
tem contains  three  robotic  workcells  that  prepare  components,  test  components,  and 
insert  components  into  circuit  boards,  respectively.  Only  the  component  selection 
process  for  the  first  robotic  cell  will  be  discussed,  i.e..  the  one  that  prepares  the  com- 
ponent. In  this  workcell,  an  electronic  component  is  picked  from  input  kitting  trays, 
the  leads  are  straightened  (formed),  trimmed,  and  then  flux  and  solder  b applied  to 
the  leads  before  placing  the  component  in  the  exchange  nest  for  the  second  robot. 

Initially,  the  workcell  designer  enters  the  overall  function  PREPARE, 
which  b manually  matched  with  the  PROCESS  function  in  the  functional  hierarchy. 
Now.  the  system  does  two  tasks:  (a)  The  Ml  mappings  are  checked  for  a functionally 
specific  mapping  on  PROCESS.  A mapping  is  functionally  specific  on  a function,  F, 
if  the  mapping  contains  only  that  function,  F.  Similarly,  a mapping  b structurally 
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mapping  exists  for  the  functional  object  PROCESS.  If  a mapping  existed,  the  syv 
tem  would  present  the  designer  with  the  alternative  structural  options,  (b)  From 
Figure  6.2.  the  functional  object  PROCESS  is  an  F-AGG  abstraction  on 
TRANSFER  and  OPERATE.  Therefore,  the  system  decomposes  PROCESS  into 
TRANSFER  and  OPERATE  and  analyzes  them  in  turn. 

The  functionally  specific  Ml  mapping  for  TRANSFER  is  m„  with  struc- 
tures Electronic-Component  and  Circuit-Board.  The  designer  is  presented  with  this 
Component.  The  system  then  finds  a structurally 


p for 


. The 


corresponds  to  alternative  functions  CARRY,  FORM.  TRIM,  and  SOLDER:  call  this 

TRANSFER.  The  subfunctions  of  TRANSFER  (from  Figure  6.2)  are  CARRY  and 
SLIDE;  call  this  set  {«},.  The  intersection  of  {Fi),  and  {F.},  gives  CARRY.  The 
system  presents  the  functional  object  CARRY  to  the  user  who  accepts  it. 

The  functionally  specific  Ml  mapping  for  CARRY  is  m,3  with  structures 
Robot.  Gripper,  and  Workpiece  (Electronic-Component  is  a Workpiece).  As  these 
structures  are  of  interaction  type  (i)  of  section  3.3.2.2,  the  system  selects  all  these 
structures.  CARRY  is  decomposed  to  functions  PICK,  MOVE,  and  PLACE  (see 
Figure  6.2).  Using  m„,  m15,  and  m18  the  system  generates  the  associated  structures 
for  these  functions,  respectively.  In  the  case  of  the  PICK  function,  the  structures  are 
Kitting-Tray,  Exchange-Nest,  and  Test-Bench.  To  select  the  appropriate  structure, 
the  system  either  consults  the  designer  or  uses  the  context  information  (gathered  so 
far)  based  on  the  structurally  specific  Ml  mapping  associated  with  the  functional 
object  PICK.  No  such  structure  exists;  therefore,  the  designer  manually  selects 
Kitting-Tray.  It  is  the  same  for  the  functional  objects  MOVE  and  PLACE,  and  the 
designer  has  to  select  the  appropriate  structures  manually. 


The  functionally 
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The  system  now  analyses  the  OPERATE  function, 
specific  Ml  map  for  OPERATE  is  m„,  from  which  the  user  selects  the  structural 
object  Electronic-Component.  As  in  the  TRANSFER  case  (above),  the  system  uses 
the  functional  context  information,  (now  the  context  is  OPERATE),  to  present  the 
alternative  functions  TRIM.  FORM,  and  SOLDER  to  the  user.  The  designer  selects 

objects  are  Robot,  Grippers,  Kitting-Tray,  Former-Bench,  Cutter,  Flux_Pot,  and 
Solder-Pot;  the  functional  objects  are  PROCESS,  TRANSFER,  OPERATE. 
CARRY,  PICK,  MOVE.  PLACE,  TRIM,  FORM,  and  SOLDER. 

For  completeness,  a few  points  arc  worth  mentioning,  (a)  Objective  func- 
tions based  on  the  properties  of  the  objects  such  as  cost,  power  consumption,  and 
space  limitation  are  used  (along  with  the  context  information)  to  reduce  the  number 
of  alternative  structural  objects  and  functional  objects  presented  to  the  designer,  (b) 
These  components  are  now  arranged  in  the  workceil.  This  layout  is  then  simulated 
to  generate  the  cycle  time,  i.e.,  the  average  time  it  takes  for  the  workcell  to  produce 

This  example  brings  out  the  following  advantages  of  the  SF  paradigm  for 
modeling  engineering  information; 

(a)  The  independent  definition  of  structural  objects  and  functional  objects  provides  a 


(b)  Alternative  structural  implementations  of  a functional  requirement  and  alterna- 
tive behavior  of  a physical  object  are  naturally  modeled  with  this  paradigm. 

Below,  an  algorithm  is  presented  to  select  structures  (functions)  for  a design 
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1.  For  each  element,  f,  in  a set  of  functional  objects,  F,  do 

(a)  Use  functionally  specific  Ml  mapping  on  f to  get  alternative  sets  of  struc- 
tural objects  {Si}. 

(b)  Decompose  f into  subfunctions. 

(i)  If  f is  an  F-AGG,  decompose  f into  a set  of  subfunctional  objects  F'. 
Place  F' in  F.  Goto(l). 

(it)  If  f is  an  F-GEN.  decompose  f into  alternative  sets  of  functional 
objects  {Fi}. 

2.  For  each  clement,  s,  in  a set  of  structural  objects,  S,  do 

(a)  Use  structurally  specific  Ml  mapping  on  s to  get  alternative  sets  of  func- 
tional objects  {Fi}. 

(b)  Decompose  s into  substructures. 

(!)  If  s is  an  AGGregation,  decompose  s into  a set  of  substructure! 
objects  S'.  Place  S’  in  S.  Go  to  (2). 

(ii)  If  s is  a GENeralization,  decompose  s into  alternative  sets  of  struc- 
tural objects  {Si}. 

3.  For  alternative  sets  of  functional  objects  {Fi}.  pick  F e {Fi}  by  either  using  func- 
tional contexts,  user  intervention,  or  both. 

4.  For  alternative  sets  of  structural  objects  {Si},  pick  S c {Si}  by  either  using  struc- 
tural contexts,  user  intervention,  or  both. 

This  algorithm  is  an  intelligent  aid  that  guides  the  designer  in  selecting 
components  for  a design,  in  this  case,  robotic  workcells.  The  algorithm  uses  a data- 
base of  structural  objects,  functional  objects  arranged  in  well-defined  hierarchies,  and 
the  Ml  associations  between  these  domains  to  select  structures  and  functions. 
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6-3.1  Common  Data  Model 


This  section  shows  how  the  SF  paradigm  is  represented  in  the  OSAM*. 
The  structural  object,  functional  object,  and  the  interaction  object  or  the  SF  para- 
digm are  complex  objects  and  are  represented  as  a set  of  well-defined  OSAM* 
classes.  Therefore,  a complex  OSAM*  class  is  a collection  of  classes  whose  definition 
represents  the  structural  template,  functional  template,  and  interaction  template  (in 
Chapter  3). 

6-3. 1.1  Structure!  ' : 

A complex  OSAM*  class  that  represents  a structural  template  is  shown  in 
Figure  6.5.  The  top-level  class  is  called  the  structural  object  and  contains  the  name 
and  id  of  the  complex  structural  object.  This  object  class  is  aggregated  from  two 
subclasses  called  the  structural  external  features  and  the  structural  internal  features. 
The  structural  external  features  class  represents  the  features  that  connect  the  struc- 
tural object  to  other  objects.  Internal  features,  in  turn,  are  aggregated  from  three 
classes  called  the  property  class,  structural  component  class,  and  assembly  relation 
class,  which  represent  the  state  variables,  component  declarations,  and  associations 
among  components,  respectively.  These  classes  are  the  system-defined  classes  and 
together  constitute  a complex  structural  object  class.  All  user-defined  classes  (e.g., 
the  class  or  circuits,  a class  of  AND  gates)  form  a generalization  hierarchy  under  the 
structural  object  class  and  inherit  the  complex  class  definition  of  the  structural 
object.  The  insertion  and  deletion  of  instances  in  these  classes  are  subject  to  the  con- 
straints in  section  4.2.4. 


Functional  objects 


A complex  OSAM*  class  that  represents  a functional  template  is  shown  in 
Figure  6.6.  The  top-level  class  is  called  the  functional  object  and  contains  the  name 
and  id  of  the  object.  This  class  is  aggregated  from  the  functional  external  features 
class  and  the  functional  internal  features  class.  External  features  are  aggregated 
from  input  class,  the  output  class,  and  the  functional  specification  class,  which 
represent  the  input  variables,  output  variables,  and  the  functional  specification  or  the 
functional  object,  respectively.  Internal  features  are  aggregated  from  the 
state-output  function  class,  functional  component  class,  and  connection  relation  class, 
which  represent  the  state-output  function  declaration,  component  function  declara- 
tions. and  relationships  among  functional  components,  respectively.  As  in  the  struc 
tural  object  case,  all  user-defined  classes  form  a generalisation  hierarchy  under  the 
functional  object  class  and  inherit  the  complex  class  structure. 

6.3.1.3  Interaction  objects 

A complex  OSAM*  class  that  represents  an  interaction  template  is  shown 
in  Figure  6.7.  The  top-level  class  is  called  the  interaction  object  and  contains  the  id 
of  the  object.  This  class  is  aggregated  from  a class  called  scope  and  a class  called 
mappings.  The  scope  class  defines  the  structural  objects  and  the  functional  objects 
related  by  this  interaction  object.  The  mappings  class  is  the  aggregation  of  the  Ml 
mapping  class,  the  M2  mapping  class  and  the  M3  mapping  class.  The  BIND  and 
FREE  operators  are  associated  with  the  Ml  mappings;  the  GET  and  PUT  operators 
are  associated  with  the  M2  mappings.  Data  can  be  inserted  and  deleted  into  these 
classes  to  reconfigure  the  interconnection  among  structural  and  functional  objects. 
Note  that  the  instances  of  the  interaction  objects  relate  the  structural  and  functional 
information  both  at  the  class  level  and  the  instance  level. 
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Figure  6.5  Complex  structural  OSAM*  CLASS. 
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Figure  6.6  Complex  fu 


OSAM*  CLASS. 


So,  OSAM*  is  sufficient  to  represent  the  constructs  of  the  S-F  paradigm. 
Here,  the  active  component  of  the  domain  is  modeled  explicitly  and  distinctly  from 
the  structural  configuration  of  the  domain.  The  execution  model  of  the  S-F  para- 
digm, i.e.,  the  activation  and  deactivation  of  complex  functional  objects,  the  interac- 
tion cycle  and  the  execution  cycle,  can  be  built  on  top  of  the  OSAM*  classes. 

6.3,2  C1M  Architecture 

Distributed  CIM  architecture  integrates  domain-specific  expert  systems, 
specialized  application  programs,  and  distributed  heterogeneous  database  systems 
into  one  framework.  A distributed  architecture  is  suited  for  engineering  projects  that 
span  several  information  technologies  which  are  located  in  different  regions  or  coun- 
tries, and  that  need  to  handle  multiple  views  of  large  volumes  of  data  and  knowledge 
across  heterogeneous  systems  in  a consistent  and  unifying  manner. 

Figure  6.8  shows  a high-level  integrated  structural  architecture  for  a distri- 
bvUi  CIM  environment,  (DCE).  The  DCE  architecture  inherently  shares  widely 
dispersed  and  possibly  replicated  data  and  knowledge  with  applications  such  as 
engineering  design,  process  planning,  and  manufacturing.  The  main  feature  of  this 
architecture  is  the  modular  integration  of  a range  of  intelligent  user  interfaces,  appli- 
cation tools,  and  design  workspaces,  with  information  on  existing  designs,  available 
parts,  design  features,  machine  tools,  and  material  properties.  These  sets  of  informa- 
tion are  integrated  by  a set  of  dictionaries  that  provide  (a)  schema  integration  among 
databases,  application  programs,  and  user  interfaces;  (b)  location,  fragmentation  and 
replication  transparency;  and  (c)  security  through  controlled  access  to  information 
across  the  network.  The  DCE  architecture  consists  of  four  logical  levels:  (a)  user 
interfaces;  (b)  tools;  (c)  design  workspaces;  and  (d)  enterprise  knowledge. 


6.3.2.1  User  interface 


A user  interacts  with  the  system  through  any  one  of  the  user  interfaces.  A 
user  interface  is  specific  to  an  application,  e.g.,  a worked!  designer  will  use  a custom- 
ized interface  that  selects  workcell  components,  constructs  worked!  models  by  laying 
out  these  components,  and  then  tests  these  models  for  correctness  of  operation. 
Similarly,  mechanical  engineers  will  use  2-D  or  3-D  graphical  editors,  and  application 
programmers  use  text  editors,  icon-based  systems,  or  form  generators.  All  these  user 
interfaces  aim  to  insulate  the  end  user  from  interacting  with  the  system  through  an 
unfamiliar  database  query  language,  or  from  becoming  familiar  with  the  subtleties  of 
accessing  information  from  across  a distributed,  heterogeneous  database  system.  The 
function  of  the  interface  is  to  collect  information  from  the  user  and  display  informa- 
tion from  the  system  in  a user-friendly  format.  These  interfaces  are  not  restricted 
only  to  users,  but  also  interact  with  physical  systems  such  as  sensors  and  actuators  to 
receive  and  transmit  data  and  control  to  the  external  world. 

S.3.2.2  Tools 

Tools  are  a set  of  application  programs  that  perform  specialized  tasks  such 
as  design,  verification  of  design,  simulation,  process  planning,  monitoring  of  manufac- 
turing processes,  generating  NC  machine  part  programs,  and  scheduling  of  customer 
orders.  These  tools  are  physically  distributed  across  the  network,  but  their  locations 
are  transparent  to  the  user.  These  tools  are  mapped  to  the  user  interfaces,  and  this 
mapping  information  is  stored  in  the  user  interface-tools  information  mapping  dic- 
tionary (UIT  dictionary).  The  UIT  dictionary  contains  mapping  information 
between  input-output  formats  among  tools  and  user  interface  packages,  and  the  loca- 
tions of  the  tools  and  interfaces  across  the  network.  These  tools  either  (a)  generate 
data  which  are  then  stored  into  the  underlying  database  system,  (b)  consume  data 


from  the  underlying  database  system  by  generating  queried  or  (c)  transform  data 
from  the  output  of  one  tool  in  order  to  be  compatible  with  the  input  of  other  tools. 
In  many  systems,  specialized  tools  have  their  own  interfaces  built  into  the  application 
packages,  so  these  two  layers  in  the  architecture  (i.e.,  the  user  interface  and  tools) 
will  be  replaced  by  one,  user-friendly  application  package. 

6.3.2.3  Design  workspaces 

Every  user  uses  a workspace.  A workspace  is  an  information  holding  area 
which  allows  the  user  to  cache  relevant  data  and  knowledge  needed  during  design, 
process  planning,  or  any  other  activity.  All  workspaces  are  assigned  to  a project 
cluster.  The  project  cluster  is  a collection  of  workspaces  assigned  to  a group  of  peo- 
ple who  frequently  share  information  across  the  DCE,  e.g.,  a design  team.  Project 
clusters  are  independent  of  each  other  and  do  not  share  information,  thus  protecting 
information  by  limiting  a workspace  to  only  those  access  privileges  granted  to  its 
cluster.  There  is  one  working  design  database,  (WDD)  in  a project  cluster  which 
communicates  with  each  workspace  (in  the  project  cluster),  and  holds  the  consistent 
integrated  application  view  (schema)  of  all  these  workspaces.  For  example,  a 
workspace  can  check-out  a portion  of  an  ongoing  design  from  the  WDD  and  modify 
it  before  checking-in  an  updated  version.  The  WDD  ensures  that  the  checked-in 
design  is  consistent  throughout  the  WDD  (i.e,  acceptable  to  all  the  other  workspaces) 
before  integrating  it  with  the  overall  design.  To  ensure  consistency  of  the  overall 
conceptual  schema,  the  WDD  often  runs  verification  and  simulation  tests  against  the 
new  intergrated  schema.  These  tests  produce  large  volumes  of  data  that  have  a 
finite  life  cycle;  these  data  are  stored  in  the  time-sensitive  data  store.  The  working 
design  database  and  the  workspaces  allow  a project  cluster  to  support  evolution  of 
designs  in  an  integrated  CIM  environment.  Physically,  workspaces  of  two  or  more 
project  clusters  can  belong  to  one  site,  or  the  workspaces  of  one  project  cluster  can 


be  dispersed  over  many  sites.  This  distribution  is  transparent  to  the  WDD.  The 
mapping  between  workspaces,  working  design  databases,  and  tools  of  a project  data- 
base are  stored  in  the  tools-design  workspace  information  mapping  dictionary  (TDW 
dictionary).  This  directory  holds  the  mapping  information  between  the  external  data 
schemas,  external  process  schemas  and  the  application  schemas  (described  in  subsec- 
tion 6.3.3  below)  specific  to  a project  cluster. 

6. 3.2.1  Enterprise  knowledge 

The  enterprise  data  and  knowledge  are  stored  in  a set  of  globally  distri- 
buted databases  and  knowledge  bases.  The  enterprise  information  includes  (a)  exist- 
ing proven  designs  classified  by  their  functionality  to  avoid  rediscovering  a proven 
concept  and  to  cross-reference  results  from  two  or  more  domains  to  aid  in  innovative 
design  effort;  (b)  parts  classified  according  to  design  and  manufacturing  parameters 
for  use  in  discreet  assembly,  and  materials  data  stored  by  one  (or  many)  accepted 
national  standards;  (c)  primitive  features  information  that  is  used  to  define  the  struc- 
ture (or  form)  of  engineering  designs  and  to  associate  them  to  manufacturing  opera- 
tions and/or  process  plans;  and  (d)  information  and  constraints  on  machines  based  on 
capability  and  performance.  This  information  is  replicated  across  the  DCE  depend- 
ing on  the  frequency  of  use,  reliability,  performance,  and  security  of  the  information. 
As  this  information  is  not  frequently  updated,  the  overheads  associated  with  ensuring 
consistency  and  integrity  across  the  sites  are  negligible.  The  design  workspace  data- 
bases knowledge  base  (DWDKB)  information-mapping  dictionary  integrates  the 
enterprise  information  (i.e.,  databases  and  knowledge  bases)  at  the  schema  level  by 
defining  a set  of  global  conceptual  schemas  and  global  process  schemas.  The 
DWDKB  dictionary  also  holds  the  mappings  between  the  global  schemas  and  the 
external  schemas  specific  to  the  project  cluster. 
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In  short,  the  DCE  architecture  provides  an  integrated  view  of  the  entire 

or  more  application  tools  through  one  of  the  user  interface  packages  in  a project  clus- 
ter. This  application  tool  consults  other  tools  and  uses  the  enterprise  data  and 

analysis,  or  manufacturing  data.  Integration  among  these  four  levels  are  stored  in 

entire  system  is  overseen  by  the  global  dictionary,  called  the  integrated  manufactur- 
ing system  dictionary  (IMSD)  (sec  Figure  6.8).  The  IMSD  Is  replicated  across  major 

apart  if  the  site  containing  the  IMSD  crashes  or  is  isolated  from  the  rest  of  the  sys- 

6.3.3  Integration  in  CIM  Environment 

This  section  describes  how  the  components  described  in  section  6.3.2  are 
integrated  into  one  system.  The  architecture  is  an  extension  of  the  distributed 

and  Heimbigner  and  McLeod  (LAN82,  HEI85|.  The  purpose  of  this  architecture  is  to 
provide  a uniform  logical  integrated  system  of  databases  and  application  programs. 
The  architecture  consists  of  several  layers:  the  top  layer  is  the  user's  view  of  the  sys- 
tem, the  bottom  layer  is  the  actual  physical  or  structural  configuration  of  the  system, 

modular  way  so  that  new  components  can  be  added  or  deleted  with  minimum  effort. 

The  integrated  CIM  architecture  consists  of  (a)  the  integration  of  distri- 
buted databases,  (b)  the  integration  of  application  processes,  and  (c)  the  integration 
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6.3.3.1  Local  schemas 

description  of  an  application  program(s),  for  example,  an  analysis  package,  simulation 
package,  etc.  The  local  process  schema  describes  the  application  packages  by  its 
input  and  output  features  and  its  capability  specification.  The  global  process  schema 
uses  these  external  feature  specifications  to  integrate  two  or  more  application  pro- 
grams. 

schemas  that  are  geographically  distributed,  have  their  own  database  models  and 
languages,  and  run  on  independent  systems.  To  integrate  these  local  database  sche- 
mas, each  local  schema  has  a set  of  export  schemas  [HEI85|.  An  export  schema  is  a 

with  the  rest  of  the  system.  The  export  schema  defines  the  access  privileges  to  the 
data  in  the  local  site. 

5.3.3.2  Global  schemas 

Global  process  schema.  The  global  process  schema  represents  an  integrated 
view  of  application  programs  in  the  system.  The  global  process  schema  interconnects 
a set  of  local  process  schemas  through  a process  called  process  integration.  There  are 
many  global  conceptual  schemas  in  the  system,  all  of  which  are  described  by  some 
common  data  model  such  as  OSAM*. 

Process  integration  starts  with  the  functional  specification  of  the  application 
programs  os  described  in  subsection  3.2.2.I.  These  functional  specifications  are 
described  by  a set  of  capabilities,  each  of  which  denotes  one  functional  characteristic 
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of  the  program.  These  functional  specifications  are  classified  on  their  common  capa- 
bilities into  an  associative  classification  DAG.  The  different  kinds  of  capability  types 
and  the  algorithms  for  building,  evolving,  and  querying  this  classification  DAG  are 
described  in  detail  in  Cornelio  and  Navathe  [COROOb]. 

Once  the  associative  classification  DAG  is  built,  the  system  designer  uses  it 
to  generate  a global  process  schema.  The  global  process  schema  is  expressed  in 
terms  of  its  functional  specification,  i.e.,  what  the  integrated  process  is  expected  to 
accomplish.  This  specification  is  similar  to  the  ones  used  for  the  functional  object. 
The  functional  specification  of  the  global  process  schema  is  posed  in  the  form  of  a 
query  to  the  classification  DAG.  The  classification  DAG  then  suggests  a set  of  appli- 
cation program  functional  specifications  which  partially  match  the  global  process 
schema  functional  specifications.  This  set  of  specifications  is  presented  to  the  system 
designer,  who  then  manually  specifies  the  order  in  which  these  processes  have  to  be 
interconnected.  The  designer  then  specifies  the  mappings  between  the  inputs  and 
outputs  of  these  programs.  The  mappings  are  similar  to  the  connection  relations 
described  in  sections  3.2.2  and  3.7.  If  there  is  an  incompatibility  between  the 
output-input  variable  pairs,  the  system  detects  the  incompatibility  and  links  data 
translation  routines  to  these  pairs.  At  the  end  of  this  process,  the  global  process 
schema  describes  the  interconnection  between  a set  of  application  programs  that  per- 
form a described  task  by  generating  an  integrated  process  schema  of  functional 
object  descriptions.  A global  process  schema  is  defined  by  a common  data  model 
(OSAM*)  and  it  is  represented  by  a hierarchy  or  DAG  of  complex  functional  objects 
described  in  Chapter  3.  The  global  process  schema  is  stored  in  the  DWDKB 
information-mapping  dictionary  shown  in  Figure  6.8. 

Global  conceptual  schema.  The  global  conceptual  schema  is  an  integrated 
view  of  the  system  data.  There  are  many  such  global  conceptual  schemas  in  the  sys- 
tem. all  of  which  are  described  by  a common  data  model  (OSAM*)  and  have  a 


common  data  definition  and  manipulation  language.  The  global  conceptual  schema 
is  constructed  from  a set  of  import  schemas  which  describe  the  data  it  needs  from 
the  export  schemas  defined  on  the  local  database  schemas.  These  export  schemas  arc 
first  translated  from  their  individual  data  models  to  the  common  data  model 
(OSAM*)  and  are  then  integrated  by  a schema  integration  software  tool,  like  the  one 
described  in  Sheth  et  al.  [SHE88|.  The  global  conceptual  schema  shields  the  external 
schemas  and  the  application  schemas  from  (a)  the  incompatibilities  in  the  local  data- 
bases, (b)  from  the  distribution  of  data  across  the  network,  and  (c)  the  replication 
and  fragmentation  of  data  (CER83,  NAV84).  It  translates  a global  query  to  the  indi- 
vidual local  database  schemas  [LAN82],  collects  the  results  of  the  query,  and  presents 
the  results  to  the  application  schema.  The  global  conceptual  schema  is  stored  in  the 
DWDKB  information-mapping  dictionary  shown  in  Figure  6.8. 

6.3.3.3  Virtual  data  schema 

During  an  application,  large  quantities  of  data  are  produced  and  consumed 
by  the  external  process  schema.  Some  of  these  data  will  not  be  described  in  the 
external  database  schema:  also,  some  of  these  data  have  a finite  life  span  and  will  not 
be  stored  as  persistent  data  in  the  database.  Therefore,  these  data  are  stored  in  the 
time-sensitive  data  store  described  in  subsection  6.3.2.3.  A virtual  data  schema  con- 
sists of  data  items  that  are  specified  ns  either  inputs  or  outputs  of  the  objects  in  the 
external  process  schema  but  are  not  present  in  the  external  conceptual  schema. 
Therefore,  a virtual  data  schema  is  particular  to  a specific  external  process  schema 
and  external  database  schema.  For  example,  the  data  generated  by  a simulation 
package  is  specific  to  the  simulation  run,  the  input  data  (from  the  external  database 
schema),  and  the  simulation  package  (from  the  external  process  schema).  These 
simulation  data  ore  required  by  a diagnostic  package,  but  the  test  designer  has  no 


intention  of  storing  this  inforn 


’ In  the  database. 


6.3.3.-I  External  schemas 


External  process  schema.  The  external  process  schema  is  a set  of  functional 
objects  that  describe  the  relationship  between  two  or  more  application  programs 
which  are  specific  to  an  application.  The  external  process  schema  (a)  controls  the 
order  of  execution  of  the  application  tools,  (b)  conducts  compatibility  checks  between 
the  inputs  and  outputs  among  these  tools,  and  (c)  resolves  these  incompatibilities 
with  data  translation  routines.  The  external  process  schema  is  a subset  of  the  global 
process  schema,  and  it  is  stored  in  the  working  design  database  (Figure  6.S)  of  each 
project  cluster.  The  mappings  between  the  external  process  schema  and  the  global 
process  schema  are  stored  in  the  DWDKB  information-mapping  dictionary  shown  in 
Figure  6.8. 

External  database  schema.  An  external  database  schema  is  an  external  view 
of  the  global  conceptual  schema  and  is  specific  to  a project  cluster.  It  describes  only 
the  data  needed  for  a particular  project.  The  external  database  schema  is  stored  in 
the  working  design  database  (Figure  6.8)  of  each  project  cluster.  The  mappings 
between  the  external  database  schema  and  the  global  conceptual  schema  arc  stored 
in  the  DWDKB  information-mapping  dictionary  shown  in  Figure  6.8. 

6.3.3.5  Application  schema 

An  application  schema  is  the  integrated  view  of  the  system  as  seen  by  the 
end  user.  There  are  many  such  application  schemas  in  the  system,  one  per  project 
cluster  (see  Figure  6.8).  The  application  schema  uses  the  SF  paradigm  to  integrate  a 
set  of  application  programs  (or  processes)  declarations  in  the  external  process  schema 
with  the  data  in  the  external  database  schema.  The  external  process  schema  is 
represented  by  an  integrated  set  of  functional  objects;  the  external  database  schema 
is  represented  by  an  integrated  set  of  structural  objects.  The  integration  of  the 
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application  programs  with  the  database  is  done  by  combining  the  structural  object 
declarations  of  the  external  database  schema  with  the  functional  object  declarations 
of  the  external  process  schema  by  using  the  Ml,  M2,  and  M3  mappings  of  the 
interaction  objects  (in  the  SF  paradigm). 

The  Ml  mappings  specify  which  structural  object  class  (i.e.,  an  OSAM* 
complex  class)  relates  to  an  functional  object  class  (also  an  OSAM*  complex  class). 
For  example,  the  class  of  ail  electric  circuits  will  be  related  to  a circuit  analysis  pro- 
gram, or,  at  a lower  level,  a class  of  AND  gates  will  be  related  to  a functional  object 
which  models  the  boolean  and  truth  table.  All  instances  of  the  class  will  automati- 
cally inherit  the  Ml  mapping  defined  on  the  class  definitions.  Therefore,  the  Ml 
mapping  is  a meta-level  mapping  between  structural  object  classes  and  functional 
object  classes. 

The  M2  mappings  relate  the  state  variables  of  the  structural  objects  (i.e., 
the  data  stored  in  the  structural  objects)  to  specific  state-transfer  functions  of  the 
functional  objects.  Specifically,  the  M2  mappings  relate  the  properties  class  of  the 
complex  structural  object  to  the  state-transfer  function  of  a complex  functional 
object.  In  many  cases  it  will  not  be  easy  to  isolate  the  specific  state-transfer  func- 
tions. Also,  the  state  variables  are  inaccessible  to  the  application  schema  designer 
due  to  proprietary  reasons.  In  any  case,  however,  the  state-output  function  is  always 
accessible  by  the  inputs  and  the  outputs  of  the  application  programs.  The  M2  map- 
pings relate  the  input-output  variables  of  a complex  functional  object  (i.e.,  functional 
input  features  class  and  the  functional  output  features  class,  respectively)  in  the 
external  process  schema  with  the  properties  class  of  a complex  structural  object  in 
the  external  database  schema. 

In  the  integration  of  application  programs  and  databases,  there  are  some 
output  variables  of  a functional  object  that  are  not  present  in  the  external  database 
schema.  These  output  variables  in  turn  will  be  used  by  other  functional  objects. 
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These  variables  are  stored  in  the  virtual  data  schema.  The  application  schema  uses 
the  external  database  schema  and  the  virtual  data  schema  to  store  data,  the  external 
process  schema  to  represent  application  programs,  and  the  interaction  objects  to 
integrate  these  schemas  together.  The  external  database  schema  describes  the  per- 
sistent data  of  the  application  schema,  whereas  the  virtual  data  schema  describes  the 
nonpersistent  data  of  the  application  schema.  During  run  time,  the  application 
schema  uses  the  Ml  mappings  to  bind  functional  objects  from  the  external  process 
schema  with  a specific  object  class  in  the  external  database  schema  and  the  virtual 
data  schema,  and  the  M2  mappings  to  read  and  write  data  values  between  these 
objects,  respectively. 

For  example,  consider  an  external  process  schema  consisting  of  a circuit 
generator  package  specification,  fl,  and  a circuit  simulation  package  specification,  12. 
The  input  to  fl  is  the  specification  of  the  circuit,  and  the  output  of  fl  is  the  topology 
of  the  circuit.  The  inputs  of  f2  are  the  topology  of  the  circuit  and  the  test  inputs, 
and  the  output  is  the  response  of  the  circuit.  The  external  database  schema  consists 
of  the  input  specification  data,  a set  of  object  classes  to  capture  and  hold  the  topol- 
ogy of  the  circuit  in  the  database,  and  a set  of  classes  which  contains  test  inputs. 
The  virtual  data  schema  consists  of  objects  to  capture  the  response  of  the  circuit. 

The  Ml  mapping  relates  fl  to  the  object  class  that  contains  the  input 
specifications  and  the  objects  that  hold  the  circuit  topology,  and  relates  f2  to  object 
classes  that  hold  the  circuit  topology  and  to  object  classes  that  hold  the  circuit 
response.  The  M2  mappings  specify  which  inputs  and  outputs  of  fl  and  f2  (i.e.,  the 
functional  input  features  and  the  functional  output  features,  respectively)  relate  to 
the  attributes  of  the  objects  in  the  external  database  schema  and  the  virtual  data 
schema.  During  runtime,  the  interaction  cycle  in  Chapter  3 uses  the  Ml  mappings  to 
bind  fl  and  12  to  the  different  complex  structural  objects,  and  uses  the  M2  mappings 
to  read  and  write  data  to  the  external  database  schema  and  the  virtual  data  schema. 
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this  mismatch  and  automatically  invoke  predefined  data  translation  routines  stored  in 
the  application  schema.  These  data  translation  routines  include  simple  translations 
such  as  integeMo-character,  floating  point-to-character,  etc.,  or  more  advanced 
translations  such  as  picture-to-text  or  aggregation  of  data  values  over  fields  (or  set  of 
fields)  of  the  structural  objects.  In  cases  where  the  translation  cannot  be  done 

This  section  very  briefly  outlined  the  components  and  the  functionality 
needed  to  build  an  integrated  architecture  for  a CIM  environment.  It  is  apparent 
that  this  system  will  use  all  the  existing  results  of  distributed  database  design 
(CER84),  database  schema  integration  [BAT86],  and  unexplored  areas  such  as  appli- 
cation program  integration  and  the  integration  of  databases  with  application  pro- 
grams (COROObj.  The  SF  paradigm  is  a step  in  the  direction  of  developing  a 

application  programs  in  complex  environments  which  contain  large  volumes  of  active 
and  passive  information. 

will  span  many  currently  disjoint  areas  of  research  such  as  distributed  databases, 
software  engineering,  user  interfaces,  and  various  fields  of  engineering  such  as  electri- 
cal, mechanical,  aerospace,  and  chemical.  It  is  apparent  that  a federated  architec- 
ture where  there  are  many  global  conceptual  schemas  and  many  global  process  sche- 

manufacturing  environment.  A single  global  conceptual  schema  and  a single  global 
is  not  feasible  (practical),  as  maintaining  the  integrity  and 


applicability  of  such  schemas  would  be  a herculean  task  due  to  the  diversity  of  data 
types  and  programs  present  in  a typical  engineering  design  and  manufacturing 

In  this  work  it  is  suggested  that  the  integration  of  processes  and  databases 
be  delayed  until  the  last  layer  of  the  functional  architecture,  i.e.,  at  the  application 
schema  level.  This  would  reduce  the  effort  needed  to  define  the  externa]  database 
schema  and  the  external  process  schema  so  that  specialists  in  data  modeling  areas 
and  software  systems  areas  can  perform  these  tasks.  The  engineer  then  only  concen- 
trates on  defining  the  application  schema  for  the  current  application.  The  decision 
whether  to  delay  the  integration  of  processes  and  databases  (as  suggested  in  this 
chapter)  or  to  perform  this  integration  earlier  at  the  global  conceptual  schema  and 
global  process  schema  levels  can  be  only  determined  after  more  research  in  this  area. 
In  either  case,  however,  the  integration  process  using  the  SF  paradigm  is  the  same. 


CHAPTER  7 
CONCLUSION 


This  dissertation  has  presented  the  power  of  an  information-specification 
paradigm  for  modeling  and  integrating  information  in  a computer-integrated 
manufacturing  environment.  Information  about  physical  systems  has  been  divided 
into  structures  and  functions.  Structures  represent  the  physical  or  logical 
configuration  of  the  domain,  whereas  the  functions  represent  the  behavior  or  response 
of  the  physical  system  to  input  stimulus.  The  structure-function  paradigm  presented 
in  this  dissertation  follows  this  philosophy  of  modeling  to  represent  complex  physical 
systems  normally  found  in  engineering  and  manufacturing  domains. 

Chapter  1 described  the  overall  problem  and  outlined  a solution.  It  also 
included  a survey  of  the  past  and  current  work  on  data  modeling  for  computer 
integrated  manufacturing.  It  was  evident  that  current  database  techniques  (except 
for  the  objectroriented  approach)  do  not  model  the  functions  of  a domain  along  with 
the  structure.  In  the  object-oriented  approach,  functions  are  embedded  in  structures 
by  a process  called  encapsulation.  Encapsulation  provides  a platform  for  data 
abstraction  by  separating  the  specification  from  the  implementation.  However,  the 
encapsulation  of  the  system  behavior  within  system  structure  makes  the  object- 
oriented  approach  too  rigid  to  represent  and  manipulate  systems  with  complex  struc- 
tural models  and  complex  functional  models. 

The  second  chapter  showed  through  examples  the  need  to  independently 
represent  structures  and  functions.  It  was  shown  that  in  physical  systems,  the 
abstraction  of  structures  and  the  abstraction  of  functions  arc  not  isomorphic;  there- 
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distorts  the  functional  model  of  the  system. 

The  third  chapter  presented  in  detail  the  structure-function  paradigm  and 
demonstrated  its  properties  and  uses.  It  showed  that  the  SF  paradigm  consists  of 
three  main  components:  the  structural  objects,  the  functional  objects,  and  the 

independently  and  are  related  by  a set  of  mappings  in  the  interaction  object.  In 
chapter  4,  a set  of  invariants  ensure  that  the  structural  objects  and  the  functional 

in  Chapter  5,  the  SF  paradigm  was  enhanced  to  model  and  satisfy  con- 
straints. Here,  the  SF  model  (of  a physical  system)  monitors  its  own  state  and 
ensures  that  this  model  reflects  the  working  of  the  physical  system  at  all  times. 

objects.  These  constraint  objects  are  a special  kind  of  functional  objects  that  test  a 
condition  and  execute  actions  based  on  the  results  of  the  tests.  As  the  propagation  of 
updates  in  the  system  are  driven  by  state  updates  (i.e.,  data  driven)  there  is  a possi- 
bility that  the  execution  will  not  terminate.  This  chapter  described  the  different 
cases  of  update  propagation  and  defined  techniques  to  detect  and  control  the  execu- 
tion of  infinite  propagation  loops. 

Chapter  6 presented  two  applications  of  the  SF  paradigm.  In  the  fiist 
application,  associations  between  structures  and  functions  were  used  with  the 
abstractions  in  the  structural  and  functional  domains  to  derive  (a)  a detailed  func- 
tional model;  and  (b)  a set  of  structural  components  needed  for  the  task.  This  pro- 
perty of  the  SF  paradigm  was  demonstrated  by  an  example  on  robotic  workceil 
design.  The  second  example  used  the  SF  paradigm  to  integrate  information  in  a 
CIM  environment.  The  CIM  architecture  integrated  distributed  databases  with  dis- 
tributed processes,  and  then  integrated  these  databases  and  processes  into  application 


schemas  by  using  the  SF  paradigm.  Here,  structures  represented  database  schema 
specifications,  functions  represented  application  program  specifications,  and  the 
interaction  objects  represented  the  integration  between  databases  and  application 
programs. 

In  effect,  in  this  dissertation  it  is  proposed  that  physical  systems  with  com- 
plex structural  and  functional  models  can  be  specified  in  terms  of  the  SF  paradigm. 
This  paradigm,  although  primarily  intended  for  engineering  design  and  manufactur- 
ing, can  be  used  in  any  domain  with  complex  behavior  or  operations.  There  are 
unlimited  applications  of  this  technique  for  specifying  information  requirements,  some 
of  which  are  stated  below. 

In  software  engineering  there  is  a need  to  rapidly  prototype  complex  sys- 
tems and  test  these  systems  for  correctness.  The  SF  paradigm  is  ideally  suited  for 
such  environments.  The  modular,  multi-abstraction-level  approach  enables  the 
designer  to  specify  the  operational  specifications  of  the  system  by  functional  objects, 
and  the  data  structures  by  structural  objects.  As  each  module  is  designed  and 
developed,  it  is  plugged  into  the  functional  model  by  replacing  the  state-output  func- 
tion specification  of  the  relevant  functional  object.  In  this  way,  software  systems  can 
be  developed  and  tested  in  a modular  fashion. 

In  planning,  usually  an  abstract  statement  of  the  task  is  known,  and  the 
detailed  physical  description  of  the  plan  is  desired.  The  abstract  task  statement  is 
represented  by  a high-level  abstract  functional  object,  which  is  further  refined  to 
more  detailed  functional  objects.  These  functional  objects  are  associated  with  a set 
of  structural  objects  which  denote  the  resources  or  physical  entities  required  by  the 
plan.  Plan  generation  will  require  a knowledge-base  model  to  derive  the  detailed 
plan  from  an  abstract  description. 

The  SF  paradigm  can  serve  as  a very  powerful  knowledge-base  model,  for 
it  has  a wide  range  of  abstraction  types.  A reasoning  system  can  use  these 
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abstractions  to  derive  new  information  on  the  physical  structure  or  the  operation  of 
the  system.  These  abstraction  types  are  structural-to-structural,  functional-to- 
functional.  structural-to-functional,  and  functional-to-structural.  Each  abstraction 
type  is  further  divided  into  aggregation  and  generalization  types.  The  SF  paradigm 
explicitly  represents  the  associations  between  structures  and  functions  and  therefore 
can  represent  the  different  facets  of  a real  world  object. 

or  operational  models  of  these  systems  to  conform  isomorphically  to  the  abstractions 
in  the  physical  models.  However,  the  mappings  in  the  interaction  objects  ensure  an 
accurate  specification  of  relationships  between  the  physical  model  and  the  behavioral 
model  of  these  systems. 

Finally,  the  generality  of  the  SF  paradigm  is  demonstrated  by  the  ability  to 

interaction  cycle  in  section  3.5.3,  or  directly  from  the  state  space  of  the  system  by 
triggering  events  as  done  by  the  execution  cycle  in  section  4.5.  This  capability  shows 
that  the  SF  paradigm  is  general  enough  to  represent  active  systems  that  are  sensitive 
to  system  state,  as  well  os  reactive  systems  that  respond  to  external  stimulus.  The 
correct  execution  of  these  two  systems  operating  concurrently  is  a subject  for  further 

The  work  in  this  dissertation  has  only  scratched  the  surface  of  this  interest- 

Some  of  these  problems  are  listed  below. 

(a)  There  is  a need  to  show  how  various  existing  data  models  can  be 
mapped  to  the  SF  paradigm  in  a distributed  CIM  environment. 

(b)  There  is  a need  to  demonstrate  how  the  SF  paradigm  can  be  built  on  a 
well-established,  object-oriented  model  such  as  OSAM*.  and  how  the  data  definition 
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lions  as  data  objects  is  needed.  This  object  manager  should  insert,  retrieve,  update, 
activate,  and  deactivate  structures  and  functions.  The  object  manager  should  be 
built  on  a storage  manager  that  stores  and  retrieves  related  information  in  physical 

(d)  A transaction  model  for  the  SF  paradigm  should  be  developed.  The 
transactions. 

(0)  A simulation  control  language  should  be  designed  and  developed  to 
activate  and  deactivate  different  levels  of  functional  objects  to  simulate  a physical 
system  at  different  levels  of  abstraction. 

(f)  The  concept  of  templates  described  in  Chapter  3 should  be  extended  to 
support  evolution  in  engineering  designs.  Design  evolution  strategics  for  the  SF  para- 
digm for  both  structural  and  functional  information  need  to  be  developed. 

(g)  A formal  reasoning  system  should  be  developed  that  takes  advantage  of 
the  abstraction  types  and  explicit  representation  of  structures  and  functions  to  reason 
about  physical  systems  from  first  principles.  There  is  some  effort  in  this  area,  as 
described  in  Chapters  1 and  2. 

(h)  There  is  a need  to  show  how  this  paradigm  supports  software  engineer- 
ing and  planning  activities. 

(1)  There  is  a need  to  control  the  integration  of  the  function-driven 
approach  (interaction  cycle  of  Chapter  3)  with  the  data-driven  approach  (execution 
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cycle  of  Chapter  4)  and  to  develop  consistency  rules  so  that  these  systems  can  work 
in  tandem  to  simulate  the  behavior  of  physical  systems. 

(j)  Practical  ways  to  integrate  processes  by  using  the  functional  object 
abstraction  techniques  described  in  section  4.3  should  be  developed. 

and  application  programs  based  on  the  SF  paradigm  and  to  expand  the  role  of  the 

to  an  active  context-dependent  triggering  system  that  automatically  detects  and 
corrects  disparities  among  inputs  and  outputs  of  programs  and  the  data  in  the  data- 

(l)  The  SF  paradigm  should  be  implemented  as  the  basis  for  storing  existing 
designs  in  an  associative,  knowledge-based  classification  system  [CORflOb],  so  that 
new  designs  can  draw  on  past  design  techniques  to  reduce  design  and  development 

(m)  The  SF  paradigm  should  be  interfaced  with  actual  processes  such  as 

that  it  can  predict  and  control  the  behavior  of  these  systems  (based  on  their  func- 
tional models)  in  real  time. 

(n)  There  is  a need  for  efficient  storage  structures  and  architectural  support 
that  exploits  the  inherent  interobject  and  intra-object  parallelism  present  in  the  SF 
paradigm  to  simulate  complex  natural  systems  in  real  time. 

(o)  Techniques  to  represent  multiple  levels  of  abstraction  of  events  should 
be  developed  so  that  the  system  will  trigger  constraints  which  will  initiate  actions  at 
the  appropriate  level  of  abstraction. 


APPENDIX 

EXAMPLE 


DEFINE  STRUCTURAL  OBJECT:  Spindle 
EXTERNAL  FEATURES 

EV^I'JT;  VI  /*  D_cvent  defined  on  diamcler,  sdl,  of  Step_l 
( (*  jVcnt  V1  triS8ers  ir  sdl  is  either  inserted  or  updated 
/ and  it  uses  m31  mapping  of  interaction  object  D1  to 
/ access  a constraint  object 
ALERT:  Dl.m31 
ON:  sdl 

WHERE  insert(sdl)  OR  update(sdl); 


depth,  kd:  real; 

EVENT:  V2  /*  D -event  defined  on  depth  of 
ALERT:  Dl.m32 

WHERE  insert(kd)  OR  update(kd); 


r,  sb:  real; 


JL, 

Step_2: 


diameter,  sd3:  real; 

EVENT:  V3  /*  D-cvent  defined  on  diameter,  a 

ALERT:  Dl.m33 
ON:  sd3 

J WHERE  insert(sd3)  OR  update(sd3); 
length,  sl3:  real; 

INTERNAL  FEATURES 
PROPERTIES 

Position:  {0..3601:  /*  state  variables 
Sprndle_flow_rate:  real; 

COMPONENTS;  /•  no  sub-comnonents 
RELATIONSHIPS;  /*  no  assembly  relations 
END  STRUCTURAL  OBJECT:  Spindle'. 


DEFINE  STRUCTURAL  OBJECT:  Bearing_Busb 
EXTERNAL  FEATURES 


in_diameter2,  bb2:  real; 
EVENT:  V5 

{ALERT:  D4.m32 ...  } 


\ aljsk  t : ut.mot  ...  I 
INTERNAL  FEATURES 
PROPERTIES 
Reaction_torque_I:  real; 
COMPONENTS; 

RELATIONSHIPS; 

END  STRUCTURAL  OBJECT:  Bearing_Busl 
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SSSS“°'  ***** 


EVENT:  V9 

{ ALERT:  Dl.mS 
INTERNAL  FEATURES 


Leakage: , 

COMPONENTS; 

RELATIONSHIPS: 

END  STRUCTURAL  OBJECT:  Sealing-Bush 


{-®™E  STRUCTURAL  OBJECT:  Threaded-Busi 
EXTERNAL  FEATURES 
in-diamcterl,  tb4:  real; 

EVENT:  VlO 

{ALERT:  D4.m35  ...  } 

in_diameter2,  tb2:  real; 

EVENT:  Vll 

{ALERT:  D4.m36...  } 

real; 

< ALERT:  D4.tr 
INTERNAL  FEATURES 
PROPERTIES 
Reaction_torque_2:real; 

COMPONENTS: 

RELATIONSHIPS; 

END  STRUCTURAL  OBJECT:  Threaded-Busi 


DEFINE  STRUCTURAL  OBJECT:  Housing 

FYTRP VI ! ppaTimec 


bore-diameter,  hb:  real; 
inport-diameter.  hd7:  real; 
outport-diameter.  hd8:  real; 
INTERNAL  FEATURES 
PROPERTIES 
Housing-iiow-rate:  real; 
Reaction_torque_3:  real; 
COMPONENTS; 


RELATIONSHIPS: 

END  STRUCTURAL  OBJECT: 
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id5.  Bearing_Busl 
><15.  Sealing-Bush 
id6.  Threaded-Bi 


END  STRUCTURAL  OBJECT:  Control-Valve. 

The  functional  objects  are  now  defined, 
functional  objects  given  in  Figure  2.3. 

spa? 


ACmffi ciSeL/iquh^; ' * * chJn-Bow  is 


EXTERNAL  FEATURES  /*  input  and  output 
Input:  chJn-flow; 

Output:  ch-out-flow; 

INTERNAL  FEATURES 

STATE-OUTPUT  FUNCTION 
INPUT:  chJn-flow 
BODY: 

f-channel(ch-in-flow) 

~'.urn(ch_out-flow)j  /*  s 


OUTPUT:  ch_out_fiow; 
COMPONENTS:  /*  no  components 
CONNECTION  RELATIONS;  /• 
DEACTIVATION  /*  « <- 


END  FUNCTIONAL  OBJECT:  Channel-Liqu 


DEFINE  FUNCTIONAL  OBJECT:  Seal-Liquid 
ACTIVATION  /•  activation  rule 

IF:  insert(s_in_flow); 

ACTIVATE:  SeaLLiquidf); 

EXTERNAL  FEATURES 
Input:  s_in_flow; 

Output:  sJeakage,  s-out-flow; 
INTERNAL  FEATURES 

STATE-OUTPUT  FUNCTION 
INPUT:  sJnJow; 

BODY: 

f-seal(s-in_flow) 


COMPONENTS; 
CONNECTION  RELATIONS: 
DEACTIVATION  /•  deactivation  rul 


Eli)  FUNCTIONAL  OBJECT:  SeaLLiqi 


DEFINE  FUNCTIONAL  OBJECT:  PassuLiouid 
ACTIVATION  ...  q a 

EXTERNAL  FEATURES 


ItKIN'AL  FEATURES 
STATE-OUTPUT  FUNCTION 
INPUT:  pJn_Ilow 
BODY: 

f-pass(p_in_flow) 

COMPONENTS  /*  functional  components 
Ciiannel_Liqidd(IN:  ciuiiUlow;  OUT:  ch-out-liow); 
Seal_Liquid(IN:  s_in_flow;  OUT:  sjeakaee  s-ont-flowt- 
CONNECTON  REALATIONS  s-out-Bow), 

CT-^/t-,^c*at'ons*l'ps  imonS  external  features  of  components 
DEACTSSNn.eLLiqUid(Chj>UUIOW);  SoaLLiquidf^^low)); 
END  FUNCTIONAL  OBJECT:  Pass-Liquid. 


ACTrWTIJONC.™NAL  OBJECT:  V**-*WW» 
EXTERNAL  FEATURES 
Input:  c_torqueJn; 

.™™utpul:  C-Passage_dim.  c-lorque_out; 
INTERNAL  FEATURES 

STATE-OUTPUT  FUNCTION 
INPUT:  c_torqueJn; 

BODY: 

f_dimension(c_torque_in) 

return(c_passage_dim.  c_torque-i 
OUTPUT:  c-passage-dim,  c_torque_out; 
COMPONENTS; 

CONNECTION  REALATIONS; 
DEACTIVATION  ... 

END  FUNCTIONAL  OBJECT:  Vary_Passage-Dimensk 


JUNCTI0NAL  OBJECT:  Support 
ACTIVATION ...  w 

EXTERNAL  FEATURES 
Input:  p-torque; 

Output:  p_reaction_torque; 
INTERNAL  FEATURES 

STATE-OUTPUT  FUNCTION 
INPUT:  p_torque 
BODY: 

f-support(p_torque) 

„ OUTPUT, 

COMPONENTS; 

nc, , CONNECTION  REALATIONS; 
DEACTIVATION  ... 

END  FUNCTIONAL  OBJECT:  Support. 


DEFINE  FUNCTIONAL  OBJECT:  Varv_PassnS1. 

ACTIVATION ...  ' g 

EXTERNAL  FEATURES 
Input:  v_torquo; 

I NTE  R XAL^'E  ATTiTiES  V_reac  tlon~torquc' 

STATE-OUTPUT  FUNCTION 
INPUT:  v_torque: 

BODY: 

f_vary_passage(v_torque) 

OUTPUT:  v^fe^tSS^l0rq,ft)! 
COMPONENTS  ‘«>^orque, 

Vary_Passagc_Dimension(IN:  o_torque_ln;  OUT:  c_passage_din 
c-torquc-out); 

Support(IN:  p_lorquo;  OUT:  p_rcaction_torquel- 
CONNECTION  REALATIONS  q| 

SEQtVary-i’assage-Dimcnsionfc-torque-out)- 
DEACTIVATION... 

END  FUNCTIONAL  OBJECT:  Vary-Passage. 


DEFINE  FUNCTIONAL  OBJECT:  Liquid-Flow  Con 
ACTIVATION...  q 

EXTERNAL  FEATURES 

Input:  fc-position.  fc-in-flow; 

Output:  fc_controlled_out_Jlow 
INTERNAL  FEATURES 

STATE-OUTPUT  FUNCTION 
INPUT:  fc-position,  fc_in_flow; 

BODY: 

f_flow_control(fo_po5ition,  fcJn-flow’ 
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return!  fc_controlled_o<it— flaw  V 
OUTPUT:  fe_eontrolle<Lout_flow 
COMPONENTS;  ' 

CONNECTION  REALATIONS; 
DEACTIVATION  ... 

END  FUNCTIONAL  OBJECT:  Liquid_Flow_Control. 


DEFINE  FUNCTIONAL  OBJECT:  Valve 
ACTIVATION ... 

EXTERNAL  FEATURES 
Input:  torque,  in_flow; 

internal' fea^es**®*’  reacUon-torque; 

STATE-OUTPUT  FUNCTION 

INPUT:  torque,  in-How;  * ' 

BODY: 

f_t(torque,  in_8ow.  Status) 

, return(StatiB);  /*  state  transfer  function  */ 
f_o(Status)^return^outJow,  leakage,  reaction-torque); 

OUTPUT;  ouiw.le'Se;" 

COMPONENTS 

Pass_Liq|iid(IN:  pJn_flow;  OUT:  p-out-Jlow,  pjeakage): 

VaryJ-assagellN:  v_torque;  OUT:  v_position.  v_reaction_torq..e)- 
CONVICTION  REALATIONS8'1'0"'  fc-"UloW;  0UT:  f^ontroiled-out-flow); 


e interaction  objects  for  the  Bow  ct 
uctural  objects,  the  functional  objet 


K2; 

FUNCTIONAL  OBJECTS 


UquiiLFIow-Controli 
CONSTRAINT  OBJECTS 
Cl,  C5,  C7 
INTERFACE 


IACTION  OBJECT:  Do 
L OBJECTS 
ControLValvc; 

' \L  OBJECTS 


M^U:  <Valve’  Flow-Control_Valvo>; 


183 


DEFINE  CONSTRAINT  OBJECT:  C2 
ACTIVATION  /•  f_start  event 

' PRIORITY:  10: 

IF:  VS  OR  V6  OR  V7; 

ACTIVATE:  C2; 

DISABLE:  no; 

EXTERNAL  FEATURES 

Bearing__Buslun_diameter2,  bb2:  real 
Bcaring_Bush.out_diameterl,  bb3:  rei 
Bearing_Bush.ouL-diameter2.  bb5-  re: 
INTERNAL  FEATURES 

ST ATE_OUTPUT  FUNCTION 
TEST: 


V6:  bb3:  real,  /•  V_events  VI 
EVENT:  Vl6 
{ 

ALERT:  D4.m32; 
FIND:  bb2; 

EVENT:  Vl7 

ALERT:  D4.m34; 
FIND:  bb5; 

(bb3  - bb2  > 5.0)  AND  (3.0  > 
ACTION:  ' k 


bS  - bb3  > 2.0) 


V5 


+ bb2; 


= bb3  - 5,  bb5  = 3+bb3, 2+bb3l; 
..,-uuo=  3-bb5.  2-bb5|; 
COMPONENTS: 

CONNECTION  RELATIONS: 
DEACTIVATION  /*  f_end  event 


END 


5TRAINT  OBJECT:  C2. 


18-1 


DEFINE  CONSTRAINT  OBJECT:  C3 
ACTIVATE ... 

EXTERNAL  FEATURES 


} ' 

3.0  > sb5  - sb2  > 2.0; 
ACTION: 

V8:  sb5  = [3.0-fsb2,  2.0+sb2|; 
V9:  -sb2  = [3.0*51)5,  2.0-sb5l: 
COMPONENTS;  1 

. CONNECTION  RELATIONS; 
DEACTIVATE  ... 

END  CONSTRAINT  OBJECT:  C3. 


DEFINE  CONSTRAINT  OBJECT:  C-l 
ACTIVATE  ... 

EXTERNAL  FEATURES 

Threaded_Bu5h.in_diaraeter2.  tb2:  i 
rhreadcd-Busb.ouLjlianietor.  tbO- 
INTERNAL  FEATURES 

STATE-OUTPUT  FUNCTION 
TEST: 

VII:  tb2:  real; 

EVENT:  V20 


VI2:  tie:  real; 
EVENT:  V2I 


eal: 

eal; 


ALERT:  D4.m36; 
FIND:  tb2; 

tb6  - lb2  > 5.0; 

ACTION: 
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ACTMTE  NSTRAINT  0BJECT:  05 
EXTERNAL 'FEATURES 

Spindle.Step_l .diameter,  sdl:  real; 
,,.^r,Bearin8-Bu5ll-in-diametcrl.  bbl:  rea 

INTERNAL  FEATURES 

STATE-OUTPUT  FUNCTION 
TEST: 


V4:  sdl  = bb2; 
COMPONENTS; 
CONNECTION  RELATIONS; 
DEACTIVATE  ... 

END  CONSTRAINT  OBJECT;  C5 


DEFINE  CONSTRAINT  OBJECT:  CB 
ACTIVATE  ... 

EXTERNAL  FEATURES 

Bearing_Bush.in_diameter2,  bb2:  real; 
Threaded_Bush.in_diameter2,  tb2:  real; 
Seaiing-Bush.in-diameter.  sb2:  real"  ' 
INTERNAL  FEATURES 

STATE-OUTPUT  FUNCTION 
TEST: 

V5:  bb2:  real; 

EVENT:  V24 

ALERT:  D4.m36; 


VII; 


FIND:  tb2; 

EvLnT:  V25 

ALERT:  D3.m31; 
FIND:  sb2; 

...  tb2:  real; 

EVENT:  V28 

ALERT:  D4.m32 
FIND:  bb2; 

EV^NT:  V2S; 

VO:  sb2:  real: 

EVENT:  V28; 

EVENT:  V24; 

bb2  = tb2-sb2;  /*  test  con 

ACTION: 

V5:  tb2  - bb2, 

VII:  bb2  - tb! 

V8:  bb2  =-sb2,  tb2  =sb2- 
COMPONENTS;  ’ 

CONNECTION  RELATIONS; 
DEACTIVATE  ... 

END  CONSTRAINT  OBJECT:  C6. 


bb2; 


Similarly,  the  other  constraint  objects  C7,  C8,  CO,  CIO 
similar  lines  as  C5  and  CO. 
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